CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES

Tamaño: px
Comenzar la demostración a partir de la página:

Download "CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES"

Transcripción

1 CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES CÉSAR ESTÉBAN CASTAÑEDA RUÍZ PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTÁ, D.C. 2009

2 Ingeniería de Sistemas Istar CIS0830-IS13 CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES Autor: César Estéban Castañeda Ruíz MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS Director JAVIER FRANCISCO LÓPEZ PARRA Jurados del Trabajo de Grado ANDRÉS BARRERA CÉSAR DÍAZ 2

3 Pontificia Universidad Javeriana Memoria de Trabajo de Grado PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS BOGOTÁ, D.C. DICIEMBRE, 2009 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS Rector Magnífico Joaquín Emilio Sánchez García S.J. Decano Académico Facultad de Ingeniería Ingeniero Francisco Javier Rebolledo Muñoz Decano del Medio Universitario Facultad de Ingeniería Padre Sergio Bernal Restrepo S.J. Director de la Carrera de Ingeniería de Sistemas Ingeniero Luis Carlos Díaz Chaparro Página 3 Preparado por el Grupo Investigación Istar- Versión /03/2008

4 Ingeniería de Sistemas Istar CIS0830-IS13 Director Departamento de Ingeniería de Sistemas Ingeniero Germán Alberto Chavarro Flórez Artículo 23 de la Resolución No. 1 de Junio de 1946 La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia 4

5 Pontificia Universidad Javeriana Memoria de Trabajo de Grado AGRADECIMIENTOS A mi familia, por su apoyo; A mis amigos, por su compañía; A mis profesores, por su paciencia. Página 5 Preparado por el Grupo Investigación Istar- Versión /03/2008

6 Ingeniería de Sistemas Istar CIS0830-IS13 Contenido INTRODUCCIÓN...16 I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO OPORTUNIDAD Ó PROBLEMÁTICA Descripción del contexto Formulación DESCRIPCIÓN DEL PROYECTO Visión Global Justificación Objetivo general Objetivos específicos II - MARCO TEÓRICO LBS Naturaleza de los LBS Tipos de LBS Sistemas de Información Geográfica (SIG) Tecnologías de Localización (LCS) III - PROCESO METODOLOGÍA PROPUESTA DESARROLLO DEL PROYECTO...35 I. Exploración previa II. Análisis III. Diseño de la propuesta IV. Diseño de la arquitectura V. Implementación REFLEXIÓN METODOLÓGICA

7 Pontificia Universidad Javeriana Memoria de Trabajo de Grado IV - RESULTADOS EXPLORACIÓN SOBRE LAS PLATAFORMAS PARA DISPOSITIVOS MÓVILES Plataformas más relevantes Resultado del estudio de las plataformas PROPUESTA PARA LA IMPLEMENTACIÓN DE LBS Propuesta de operaciones básicas en los LBS Implementación de los diferentes tipos de LBS por medio de Invocación de Método Remoto y Generación de Evento Asincrónico La información de posición como parámetro Resultados del estudio sobre la implementación de LBS ESTUDIO DE LAS CARACTERÍSTICAS TÉCNICAS DE LA SOLUCIÓN Comparación entre los diferentes mecanismos de transferencia de datos Resultados de la comparación entre los diferentes mecanismos de transferencia de datos para dispositivos móviles Formato de datos Resultados del estudio de los posibles formatos de datos PROPUESTA DE SOLUCIÓN Compilación de las características de la Solución El Middleware OMNI El Redirector y el Servidor OMNI Sesión OMNI Tipos de datos en OMNI Excepciones OMNI Servicios OMNI OMNI Middleware Protocol IMPLEMENTACIÓN Arquitectura Componentes Implementación de Servicios con OMNI Aplicaciones del Middleware OMNI PRUEBAS Latencia y Glitter Servicio de prueba chatlbs Modificación en la especificación del Middleware OMNI como resultado de las pruebas Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 7

8 Ingeniería de Sistemas Istar CIS0830-IS13 V - CONCLUSIONES Y TRABAJOS FUTUROS CONCLUSIONES TRABAJOS FUTUROS...79 VI - REFERENCIAS...80 V- ANEXOS

9 Pontificia Universidad Javeriana Memoria de Trabajo de Grado RESUMEN En los últimos años, se ha observado un crecimiento considerable en la disponibilidad y el uso de las redes inalámbricas. El acceso a los servicios remotos por medio de dispositivos móviles le otorga al desarrollador una nueva herramienta (la localización), la cual le permitirá implementar gran variedad de servicios innovadores que solo hasta ahora comienzan a explorarse. Sin embargo, existen múltiples plataformas para dispositivos móviles muy diferentes e incompatibles entre sí. Esto impone al desarrollador una carga extra para lograr que sus servicios sean accesibles desde todas ellas, trabajo que a menudo es más complejo que la implementación del servicio en sí. El "Middleware para la Definición e Implementación de servicios Genéricos independientes de la plataforma orientado a dispositivos móviles", nace de la necesidad de crear un Middleware independiente de la plataforma, que permita al desarrollador definir e implementar servicios genéricos de forma estándar, al mismo tiempo que mantiene brevedad y sencillez en consideración con los recursos limitados de un dispositivo móvil. ABSTRACT In the last years, the availability and use of wireless networks has experienced a substantial increase. Accessing remote services from mobile devices may bring developers information about user's position. This information allows the implementation of a wide variety of new and innovating services, most of them still unexplored. There are several platforms for mobile devices; it is a challenge for developers to achieve interoperability of their applications between different platforms. This effort is often more complex than the implementation of the service itself. The "Mobile-Device oriented Middleware for the Definition and Implementation of Platformindependent Generic Services" is a platform-independent middleware that allows developers to define and implement standard and generic services while preserving valuable low resources present in Mobile Devices. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 9

10 Ingeniería de Sistemas Istar CIS0830-IS13 RESUMEN EJECUTIVO Cuando se desea implementar un servicio que será accedido principalmente por dispositivos móviles, se enfrenta un gran problema: la interoperabilidad. En la actualidad, existe una variedad de plataformas que compiten por el mercado de dispositivos móviles; esto dificulta la tarea de definición e implementación de servicios porque impone al desarrollador la necesidad de ocuparse de las particularidades de cada una de ellas. Para solucionar este problema se estudiaron las tecnologías de transferencia inalámbrica de datos disponibles (WiFi, WiMax, GSM, GPRS, EDGE, UMTS, HSDPA) y los protocolos que han sido utilizados para implementar servicios exitosamente (SMS, MMS, WAP, TCP/IP, UDP/IP). Tradicionalmente en Computación Móvil se reconocen dos tipos de servicios: Servicios Pull: Son servicios de tipo RPC, que son invocados por el dispositivo móvil con ciertos parámetros para obtener un resultado como valor de retorno. Servicios Push: En este caso, el dispositivo móvil recibe información de forma asincrónica sin haberla solicitado activamente. La solución propuesta debía pues proveer las herramientas necesarias para implementar servicios de tipo Pull y Push. Después del proceso de exploración, se decidió diseñar un Middleware sobre TCP basado en XML por las siguientes razones: El protocolo orientado a conexión TCP permite la comunicación Full-dúplex, envío y recepción de información de forma asincrónica y es soportado por las principales tecnologías de comunicación inalámbrica que se usan actualmente (WiFi, WiMax, GSM, GPRS, EDGE, UMTS, HSDPA). El Lenguaje de Marcas Extensible (XML) provee un estándar independiente de la plataforma para la serialización de los datos que serán transmitidos. 10

11 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Un enfoque basado únicamente en Llamadas a Procedimientos remotos (RPC) no es suficiente, ya que la capacidad de enviar información desde el servidor al cliente de forma asincrónica (Push) no puede implementarse eficientemente. Para suplir esto, muchas aplicaciones invocan periódicamente un método remoto que verifica si determinado evento ha ocurrido o no. Esto se traduce en un tráfico de datos innecesario (y potencialmente costoso) así como en un desperdicio de la batería del dispositivo. En este trabajo, dicha aproximación se consideró inaceptable. Para eliminar este problema, además de la llamada a procedimientos remotos se decidió incluir en el Middleware la capacidad de generar eventos. Los eventos difieren de los RPC en que no se espera ningún retorno como resultado de su invocación, simplemente se utilizan para avisar que algo de interés ha sucedido. De esta forma, el Middleware propuesto define un servicio así: Una interfaz con los métodos Pull, que será implementada por el servidor. Estos métodos retornan un valor como resultado o lanzan una excepción consistente en un identificador numérico (int) y una cadena de caracteres. Una interfaz con eventos Pull, que será implementada por el servidor. Una interfaz con eventos Push, que será implementada por el cliente. Tanto los métodos remotos como los eventos pueden recibir cualquier cantidad de parámetros al ser invocados. Se definió un protocolo para la invocación de métodos remotos y la generación de eventos basado en XML-RPC, así como el estándar para los tipos de datos que se soportan y las excepciones que pueden ocurrir, tanto de usuario como de sistema. Para fines de validación de dicho protocolo, se implementó el middleware para RIM BlackBerry OS y Google ANDROID OS en Java ME, y un servidor funcional para Java SE. Dada la popularidad creciente de accesorios como el GPS que permiten al dispositivo móvil conocer su posición geográfica con más o menos precisión, los servicios pueden utilizar la información de localización como un parámetro adicional que les permitirá contextualizar sus Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 11

12 Ingeniería de Sistemas Istar CIS0830-IS13 resultados a la ubicación del usuario. Estos servicios se conocen como LBS (Location Based Services). Durante el proceso de desarrollo se encontró que el middleware propuesto es suficiente para permitir la implementación de LBS de tipo Pull, Push y Tracking (objetivo general de este trabajo), y que además puede utilizarse para la creación de servicios genéricos que no necesariamente hacen uso de la información de localización. Resultados: La implementación del Middleware se realizó de tal forma que cumple con los objetivos satisfactoriamente. Los tipos de datos que soporta el Middleware fueron cuidadosamente escogidos y definidos para lograr la interoperabilidad entre plataformas. Gracias a las extensivas pruebas de rendimiento que se llevaron a cabo pudo evaluarse el desempeño del protocolo TCP a través de la red celular. Dicho desempeño presenta ciertas particularidades que fueron tomadas en consideración. La definición de las operaciones básicas propuestas Invocación de Método Remoto y Generación de Evento Asincrónico resultó ser adecuada para la implementación de servicios LBS. El diseño de servicios bajo el esquema de interfaces remotas de Cliente y Servidor cubre el objetivo principal de la propuesta inicial para este Trabajo de Grado y lo generaliza para servicios que no son necesariamente LBS. 12

13 Pontificia Universidad Javeriana Memoria de Trabajo de Grado EXECUTIVE RESUME When a mobile device-oriented service needs to be implemented, the main problem faced by developers is interoperability. There are several platforms competing in the market of mobile devices, developers must take care of all their particular characteristics in order to successfully define and implement mobile-based services. To overcome this problem, most important wireless data transfer technologies have been studied (WiFi, WiMax, GSM, GPRS, EDGE, UMTS, HSDPA) and the protocols used by the time to successfully implement mobile-oriented services (SMS, MMS, WAP, TCP/IP, UDP/IP). Traditionally, there are two kinds of services in mobile-computing: Pull-type Services: Similar to RPC services. Mobile devices perform a method invocation with associated parameters to obtain results as return values. Push-type Services: Mobile device receives data asynchronically, without explicit request from Client. The proposed Solution should provide the necessary tools to implement both Pull and Push services. After an exploration process, a XML-based Middleware running over TCP has been designed for some reasons: TCP allows Full-Duplex transmissions, sending and receiving asynchronous data and is supported by main wireless data transfer technologies (WiFi, WiMax, GSM, GPRS, EDGE, UMTS, HSDPA). Página 13 Preparado por el Grupo Investigación Istar- Versión /03/2008

14 Ingeniería de Sistemas Istar CIS0830-IS13 Extensible Markup Language (XML) provides a platform independent standard for serialization of transmitted data. RPC-based systems are not enough to efficiently implement Push-type services. To deal with this, some applications invoke RPC procedures on a periodic basis to ask servers if certain events have occurred. This creates an unnecessary and potentially expensive data flow. In this work, that approach has been rejected. The proposed Middleware includes generation events functionality. Differently from RPC, when events are invoked there are not results awaited from such invocation; they are used only for notification purposes (Push). In the Middleware, a service is defined as: A Pull-interface implemented by Server. These procedures return a result or throw an exception. A Pull-interface of events implemented by Server. A Push-interface of events implemented by Clients. RPC procedures and Events can receive any number of parameters when being invoked. A protocol for Invocation of RPC Procedures and Remote Event generation has been defined, as well as the standard for supported data types and possible system and user exceptions. To successfully validate the proposed protocol, it has been implemented in Java ME and Java SE and tested over RIM BlackBerry OS and Google ANDROID OS platforms. Given the increased use of different LCS s that allow devices to know their current position, services use location data as an additional parameter to contextualize their results to user position. These types of services are known as LBS (Location Based Services). 14

15 Pontificia Universidad Javeriana Memoria de Trabajo de Grado During developing process it has become evident that the proposed Middleware is capable of implementing LBS of Pull, Push and Tracking types (principal goal of this work) and can also be used to implement generic services not necessarily involved with position data. Results: The Middleware was implemented in a way that successfully accomplishes all objectives of this work. Data types supported by the Middleware were carefully chosen and defined to achieve interoperability between platforms. Thanks to extensive performance tests, TCP over cellular networks has demonstrated to have some particular behavior that has been considered when designing the Middleware. Definition of proposed basic operations RPC and Remote Event Generation where enough to implement all types of LBS. Service design under remote Client and Server interfaces layout successfully accomplishes main objectives of this work and generalizes it to implement generic services, including LBS. Página 15 Preparado por el Grupo Investigación Istar- Versión /03/2008

16 Ingeniería de Sistemas Istar CIS0830-IS13 INTRODUCCIÓN Este documento describe el proceso de desarrollo del Trabajo de grado titulado Middleware para la definición e implementación de servicios genéricos independientes de la plataforma orientado a dispositivos móviles. En el transcurso de este Trabajo se propone, implementa y prueba una solución al problema de interoperabilidad entre plataformas para dispositivos móviles que surge al desarrollar servicios accedidos por medio de esta clase de dispositivos. El proceso siempre estuvo dirigido al uso eficiente de los recursos limitados de los equipos y a la preferencia por las tecnologías más recientes que muy seguramente estarán disponibles para una gran cantidad de usuarios en el futuro cercano. En la sección I Descripción general del Trabajo de Grado, el lector encontrará una visión global del Trabajo que incluye la formulación del problema, la justificación y los objetivos que se plantearon en la propuesta inicial. En la sección II Marco teórico, se introducen los conceptos y definiciones necesarios para la compresión adecuada de este Trabajo. En la sección III Proceso, se expone la metodología propuesta originalmente y qué se realizó en cada una de sus fases. Seguidamente, se consignan las diferencias entre lo propuesto y lo realizado y se justifican las modificaciones metodológicas que debieron ser realizadas durante el transcurso del proceso. La sección IV Resultados, se divide en subsecciones, cada una de las cuales trata de un factor diferente en la constitución de la solución. Al final de cada subsección se encuentran las conclusiones relevantes que finalmente son compiladas y empleadas para generar una propuesta. A continuación, dicha propuesta y su implementación asociada son explicadas y sus pruebas y resultados correspondientes presentados. 16

17 Pontificia Universidad Javeriana Memoria de Trabajo de Grado En la sección V Conclusiones y trabajos futuros, se encuentran las conclusiones que se alcanzaron tras la realización del presente Trabajo de Grado y algunos de los caminos que éste abre a futuros desarrollos. La presente memoria no pretende ahondar en los detalles técnicos de la solución propuesta ni del software implementado. Dichos detalles se profundizan en los documentos que se entregan como anexos. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 17

18 Ingeniería de Sistemas Istar CIS0830-IS13 I - DESCRIPCION GENERAL DEL TRABAJO DE GRADO 1. Oportunidad ó Problemática 1.1 Descripción del contexto En los últimos años, la creciente tecnología de interconexión entre diferentes dispositivos electrónicos y entre las redes mismas ha abierto una vasta gama de posibilidades para el desarrollo de servicios y aplicaciones. Por esto, es muy importante la exploración de las opciones que surgen al combinar las tecnologías existentes y las que muestran tendencia a popularizarse en el futuro cercano, pues se trata de una fuente de posibles aplicaciones innovadoras con gran potencial de éxito. Los teléfonos móviles han estado presentes en Colombia desde hace ya más de una década, y se han difundido ampliamente. Pero en los últimos años, con el advenimiento de la revolución móvil dejaron de ser sólo teléfonos y alcanzaron el nivel de pequeñas computadoras de bolsillo. La miniaturización de los dispositivos, los avances en la interfaz hombre-máquina y la reorientación de los servicios que prestan los operadores celulares hacia una filosofía integradora, similar a la de Internet, permitirán que en pocos años una gran cantidad de personas en Colombia [CRTC2008] y en el mundo [SASA2007], lleven en su bolsillo un dispositivo capaz de mantener un flujo de datos constante, veloz y en tiempo real con Internet. Además, una red de dispositivos móviles como los descritos agrega una nueva variable: la posición geográfica del dispositivo en un determinado momento. Dicha información puede obtenerse por medio de Servicios de Localización (LoCation Services - LCS). El servicio GPS (Global Position System) resulta particularmente interesante; según [ABIR2008], es de esperarse que en los próximos 5 años se generalice la inclusión de esta característica en los dispositivos móviles de todas las gamas. Sin embargo, la calidad del receptor GPS influye en su precisión y los dispositivos móviles de gama baja con GPS pueden no resultar lo suficientemente precisos para los servicios más exigentes. Pe- 18

19 Pontificia Universidad Javeriana Memoria de Trabajo de Grado ro, según [SADO2007], En el futuro, la creciente demanda de dichos servicios incentivará a los fabricantes a diseñar dispositivos más baratos y precisos. Cuando las tecnologías de conectividad inalámbrica y posicionamiento geográfico convergen en un dispositivo móvil, nace la capacidad de relacionar los datos de posición con la información disponible en un sistema de información geográfica para contextualizar la prestación de un servicio. Estos servicios se conocen como Sistemas Basados en la localización (Location Based Services - LBS). Recientemente, los LBS y los servicios para dispositivos móviles en general han despertado la atención del mercado, ya que tienen un gran potencial que solo hasta ahora comienza a apreciarse. A pesar de esto, las implementaciones a gran escala no han surgido rápidamente, ya que la mayoría de los servicios existentes son aplicaciones específicas para ámbitos empresariales cerrados, o son proyectos de exploración e investigación técnica para futuros desarrollos [MCMA2006]. Si bien los diferentes estándares de acceso a las redes de Internet y telefonía móvil son aceptados universalmente, La interoperabilidad entre la gran variedad de plataformas disponibles para dispositivos móviles no se había logrado [COST2002]. Era pues necesaria la búsqueda de un mecanismo que permitiera implementar Servicios genéricos para dispositivos móviles sin que los usuarios tuvieran que preocuparse por la marca o plataforma de su dispositivo al acceder a ellos. 1.2 Formulación Las redes inalámbricas y los dispositivos móviles ofrecen al usuario la posibilidad de estar conectado permanentemente y en casi cualquier lugar donde se encuentre. Esto abre la puerta a toda una nueva gama de aplicaciones, servicios, juegos, redes sociales, etc. que solo hasta ahora está comenzando a ser explorada. El principal obstáculo para el desarrollador es la poca interoperabilidad existente entre la variedad de plataformas disponibles para dispositivos móviles. El desarrollador se ve Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 19

20 Ingeniería de Sistemas Istar CIS0830-IS13 obligado a particularizar su servicio para una sola plataforma, con la consiguiente pérdida de mercado y oportunidades; o a abarcar varias de ellas con el esfuerzo y recursos que esto supone. En el caso de los dispositivos móviles la solución a los problemas de conexión y transferencia de datos frecuentemente es mucho más compleja que el servicio mismo que se está implementando. Dado que las operaciones de carga, ejecución, prueba y depuración de programas en dispositivos móviles resultan muy laboriosas aún disponiendo de emuladores; una aplicación sencilla puede demandar mucho tiempo para su implementación. Muchos servicios han resuelto el problema de la interoperabilidad haciendo uso de tecnologías que son comunes a todos los teléfonos (SMS) a costa de ser sumamente primitivos y de no aprovechar funcionalidades potencialmente presentes en el dispositivo. Dicha aproximación satisface efectivamente el esquema Pull-Push, ya que un mensaje de texto SMS puede enviarse como una solicitud de servicio (Pull), y un SMS recibido es en sí un evento asincrónico (Push). Sin embargo, la latencia de envío y recepción de un SMS dificultan la implementación de servicios más complejos o que requieran algo cercano al tiempo real. Teniendo en cuenta la creciente disponibilidad de nuevos medios inalámbricos de alta velocidad para la transferencia de datos (WiFi, EDGE, 3G) en los dispositivos móviles; se formuló la siguiente pregunta, que motivó el desarrollo del presente Trabajo de Grado: Cómo lograr la implementación de servicios genéricos para dispositivos móviles de tal forma que se utilicen eficientemente los recursos y sean independientes de la plataforma de cada dispositivo? 20

21 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 2. Descripción del Proyecto 2.1. Visión Global Durante el desarrollo de este proyecto, se realizó una exploración de las plataformas y tecnologías disponibles para la transferencia de datos en dispositivos móviles. Con los resultados de dicha exploración, se procedió a proponer una solución viable y a su implementación y prueba. Finalmente, haciendo uso del middleware obtenido como producto final, se implementó una aplicación que demuestra satisfactoriamente las funcionalidades necesarias para cumplir con el objetivo de este Trabajo de Grado Justificación El proyecto se realizó con el fin de brindar a los desarrolladores una herramienta que les facilite la tarea de diseñar e implementar servicios orientados a dispositivos móviles sin que deban preocuparse por asuntos de compatibilidad entre las diferentes plataformas. Se busca que el desarrollador pueda concentrar sus esfuerzos en el diseño de su servicio, mientras que los asuntos técnicos, de interoperabilidad y transferencia de datos son manejados por el middleware desarrollado en este trabajo Objetivo general Proponer una solución para la implementación de LBS de tipo Pull, Push y Tracking de tal forma que sean independientes de la plataforma de cada dispositivo Objetivos específicos I. Realizar una investigación exploratoria acerca de las diferentes plataformas existentes actualmente para dispositivos móviles. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 21

22 Ingeniería de Sistemas Istar CIS0830-IS13 II. III. IV. Analizar los datos obtenidos y con base en los resultados, proponer una solución al problema. Desarrollar la propuesta y diseñar la arquitectura asociada. Desarrollar una aplicación práctica que demuestre las funcionalidades básicas de la propuesta en LBS de tipo Pull, Push y Tracking. 22

23 Pontificia Universidad Javeriana Memoria de Trabajo de Grado II - MARCO TEÓRICO 1. LBS 1.1. Naturaleza de los LBS Según [GSMA2003] los LBS ofrecen a los usuarios un conjunto de servicios basándose en la posición geográfica del cliente que los solicita. Dichos servicios brindan la capacidad a humanos o máquinas de localizar geográficamente a otras personas, dispositivos, vehículos o recursos, así como de poner a disposición su propia ubicación para otros usuarios interesados. Los LBS implican dos acciones principales: Obtener la localización geográfica del usuario. Utilizar la información de localización para proveer un servicio. Un LBS puede activarse automáticamente cuando el cliente se encuentra en una localización específica. Alternativamente, el usuario mismo puede invocar el servicio para solicitar información que dependerá del sitio en que se encuentre actualmente (puntos de interés, información de tráfico, vehículos, recursos o servicios de emergencia y rescate). En [STEI2006], un LBS es presentado como la intersección de tres tecnologías diferentes: Conectividad Inalámbrica y LCS, Sistemas de información geográfica e Internet (fig. 1). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 23

24 Ingeniería de Sistemas Istar CIS0830-IS Tipos de LBS De acuerdo con [ADUS2004] existen básicamente tres tipos de LBS: Pull, Push y Tracking Pull En un servicio de tipo Pull, el Cliente solicita activamente al Servidor el envío de información. Se reconocen dos tipos [GSMA2003]: a) Cuando el servicio Pull requiere la posición del solicitante: En este caso, el servicio solicitado requiere como parámetro la posición del dispositivo móvil que lo solicita. Este tipo de servicio puede responder a preguntas como: Cuál es la estación de servicio más cercana a mi posición?. b) Cuando el servicio Pull requiere la posición de otro dispositivo: El servicio solicitado debe localizar a otro dispositivo móvil para poder ser ejecutado. Un servicio de este tipo puede responder a preguntas como: En dónde se encuentra mi hijo en este momento?. En el primer caso, el servicio puede resolverse entre el Cliente que realizó la solicitud y el Servidor. En el segundo caso, el Servidor debe averiguar la posición de un tercer actor para poder ejecutar satisfactoriamente el servicio Push En un servicio de tipo Push, El Servidor envía al Cliente información de forma asincrónica cuando ocurre un evento de interés. Este tipo de servicio responde a necesidades como: Infórmeme todas las mañanas del clima local o Avíseme cuando mi hijo llegue al aeropuerto. 24

25 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Tracking Este tipo de servicio provee reportes constantes de la posición de un objetivo. De esta forma se puede trazar su posición con respecto al tiempo. Un ejemplo sería: monitoreo de rutas de transporte público o localización de vehículo robado. Un LBS puede pertenecer a una o más de estas categorías. Por ejemplo, en un servicio para redes sociales, un usuario podría ser notificado de la cercanía con sus amigos (push, tracking), o podría solicitar información de cuantos de sus amigos han visitado el restaurante en que se encuentra en cierto momento (pull) Sistemas de Información Geográfica (SIG) Un Sistema de Información Geográfica (SIG) es un caso especial de un Sistema de Información que tiene la capacidad de integrar datos espaciales y descriptivos [MURP1995]. Un SIG puede entenderse también como un modelo computarizado que representa una zona geográfica (real o imaginaria) con determinado grado de precisión por medio de un sistema de coordenadas que permiten identificar cualquier punto de forma unívoca. Adicionalmente, para cada punto puede almacenarse la información relacionada que se considere de interés dependiendo del uso que se dará al SIG. Su potencial deviene de la posibilidad de relacionar la información en un contexto espacial para después sacar conclusiones acerca de dicha relación Tecnologías de Localización (LCS) Son las tecnologías que permiten obtener la información de localización geográfica del dispositivo móvil. En su forma más simple, el usuario mismo determina e introduce la información de posición en el dispositivo. Por ejemplo, se envía por medio de SMS un mensaje con el nombre de cierto centro comercial. Unos segundos después, el usuario recibe un nuevo men- Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 25

26 Ingeniería de Sistemas Istar CIS0830-IS13 saje SMS con información sobre las promociones o eventos que se encuentran disponibles en dicho centro comercial Triangulación de antenas Según [ADUS2004], la más utilizada es la Observación de Diferencia de Tiempo Mejorada (Enhaced Observed Time Difference EOTD) que hace parte del estándar GSM. En este sistema, el dispositivo móvil envía una señal a la torre y espera una respuesta. Como se conoce la velocidad a la cual se propagan las señales electromagnéticas, puede estimarse la distancia entre el dispositivo móvil y dicha antena. Si se realiza el mismo procedimiento con tres antenas cuya posición geográfica se conoce, se puede estimar la localización del dispositivo utilizando triangulación. En muchos países, este servicio debe estar disponible obligatoriamente en cualquier red de teléfonos celulares, ya que permite a las autoridades rastrear los aparatos en caso de emergencia o secuestro. Sin embargo, no siempre están al servicio del público en general y son sumamente imprecisos Sistemas de localización satelitales Actualmente solo existen tres de estos sistemas: ГЛОНАСС (sistema construido por la extinta CCCP, parcialmente operativo en la actualidad), GALILEO (iniciativa europea en desarrollo), y el Sistema de Posicionamiento Global (Global Position System GPS). Todos estos sistemas operan bajo el mismo principio: Una constelación de satélites gira en órbita alrededor de la Tierra, de forma tal que siempre son visibles por lo menos 6 de ellos desde cualquier punto en su superficie. 26

27 Pontificia Universidad Javeriana Memoria de Trabajo de Grado El dispositivo móvil está equipado con un receptor que tiene la capacidad de captar la señal que emiten constantemente los satélites. Se realiza un proceso similar al de la triangulación, pero en este caso en tres dimensiones. En lugar de buscar el punto de intersección entre tres circunferencias, se busca la intersección entre tres esferas. En realidad, existen dos puntos de intersección, uno sobre la superficie de la Tierra, y el otro en el espacio, muy por encima de la órbita de los satélites. El sistema GPS proporciona una precisión de hasta 3 metros, y su señal está disponible para la población civil de forma gratuita. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 27

28 Ingeniería de Sistemas Istar CIS0830-IS13 2. Transferencia inalámbrica de datos La capacidad de transferir datos de forma inalámbrica es la base para la creación de redes de dispositivos móviles. A continuación se expondrán las tecnologías más utilizadas en la actualidad Redes telefónicas celulares Las redes telefónicas celulares fueron inicialmente concebidas para prestar el servicio de telefonía móvil pero han ido evolucionando hasta convertirse en redes de transferencia de datos genéricos. Una red celular está conformada por cierto número de células que subdividen y cubren un espacio geográfico determinado. Cada una de estas células está equipada con transmisor-receptor fijo, conocido como estación base. Los dispositivos que deseen acceder a dicha red deben conectarse con la estación base correspondiente a la célula en donde se encuentran en ese momento. Si un dispositivo se desplaza y cambia de célula, también cambia de estación base de forma transparente para la aplicación que está utilizando la conexión [TANE2003] Evolución de las redes telefónicas celulares Según la tecnología utilizada, las redes telefónicas se clasifican en generaciones: 1G (Primera generación) Sistemas de transferencia de voz analógicos. 2G (Segunda generación) Sistemas de transferencia de voz digitales. Soportan la transferencia de paquetes de datos de forma limitada. 3G (Tercera generación) Sistemas de transferencia de voz y datos digitales. Permiten una conexión de banda ancha para el envío y recepción de paquetes de datos. 28

29 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 4G (Cuarta generación) Estos sistemas se encuentran en su etapa de desarrollo, actualmente no existe ninguna definición 4G. No diferenciarán entre la transmisión de voz o de datos y estarán completamente basadas en IP Tecnologías de telefonía celular Se indica al inicio de la descripción de cada tecnología la generación a la cual pertenece. En algunos casos, una tecnología se considera como una transición de una generación a otra. En este caso se utilizan indicaciones como (2.5G) GSM (Global System for Mobile communications) (2G) Este sistema es utilizado aproximadamente en el 80% de las redes celulares a nivel mundial [GSMW2009]. Se trata del estándar utilizado en Colombia. En GSM se utiliza la multiplexión por división de frecuencia, en el que cada dispositivo móvil transmite en una frecuencia y recibe en una frecuencia mayor. Se utiliza multiplexión por división de tiempo para dividir un solo par de frecuencia en ranuras de tiempo compartidas por múltiples teléfonos móviles CDMA (Code Division Multiple Access) (2G) Se utiliza en Estados unidos y es completamente diferente a GSM, ya que no divide el rango de frecuencia permitida en varios rangos estrechos, sino que permite que cada estación transmita todo el tiempo a través de todo el espectro de frecuencia. Los receptores utilizan filtros para aislar únicamente la información que les interesa, mientras descartan todo lo demás como ruido aleatorio GPRS (General Packet Radio Service) (2.5G) Se trata de una red de paquetes construida sobre GSM. Permite que las estaciones móviles envíen y reciban paquetes IP en una celda que se ejecuta en un Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 29

30 Ingeniería de Sistemas Istar CIS0830-IS13 sistema de voz. Cuando GPRS se encuentra en operación, algunas ranuras de tiempo en algunas frecuencias se reservan para el tráfico de paquetes EDGE (Enhaced Data rates for GSM Evolution) (2.5G - 3G) Es una red para el intercambio de paquetes construida sobre GSM. A diferencia de GPRS, agrega bits extra por baudio que son utilizados para la transmisión y recepción de los paquetes IP. Dependiendo de su implementación, permite mayor o menor velocidad en la transmisión de datos. Por esta razón no puede ubicarse específicamente en 2.5G o en 3G UMTS (Universal Mobile Telecommunications System) (3G) También conocido como W-CDMA, no es una evolución de GSM pero puede interactuar con ésta. Una celda CDMA puede entregar una llamada a una celda GSM de ser necesario. En teoría, permite velocidades de hasta 2Mbps HSDPA (3.5G) Existen varios sistemas de transición entre 3G y 4G. HSDPA se expone aquí porque es el que ha sido escogido por Colombia. Se trata de la optimización de UMTS/CDMA y su ancho de banda permite videoconferencias. La latencia en este sistema es de alrededor de 100ms, lo cual permite aplicaciones requieran tiempo real Redes inalámbricas no celulares Estos sistemas fueron concebidos para proporcionar acceso inalámbrico a Internet WiFi (Wireless Fidelity) Es un sistema de transferencia de paquetes de datos que utiliza ondas electromagnéticas en lugar de cables. Está definida por el estándar IEEE con el fin de emular el comportamiento de las redes Ethernet (LAN) pero inalámbricamente; por lo 30

31 Pontificia Universidad Javeriana Memoria de Trabajo de Grado tanto es completamente compatible con todos los servicios de éstas. Su cobertura práctica es de aproximadamente 100mts WiMAX (Worldwide interoperability for Microwave Access) Fue diseñada para brindar acceso a internet en zonas en las que la instalación de fibra óptica no resulta rentable. Utiliza antenas transmisoras de microondas que en teoría pueden transmitir a velocidades de hasta 70Mbps. Está descrita en el estándar IEEE Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 31

32 Ingeniería de Sistemas Istar CIS0830-IS13 3. Protocolos de transferencia de datos Se examinarán los principales mecanismos disponibles para la transferencia de datos desde y hacia los dispositivos móviles SMS (Short Message Service) Este sencillo sistema fue diseñado para la transferencia de alrededor de 160 caracteres de 7 bits desde un Servidor a un dispositivo o viceversa. Inicialmente hizo parte de la especificación de GSM, pero dada su gran popularidad las redes 3G actuales lo soportan. Es muy fiable y hace uso eficiente de las transmisiones por radio, ya que está relacionado estrechamente con el hardware del teléfono y la infraestructura de la red celular misma. Como parte de las funcionalidades de bajo nivel de las diferentes plataformas, el programador tiene acceso a un API que le permite implementar aplicaciones que envíen y reciban SMS para suplir sus necesidades de transferencia de datos. En el caso de Java ME, este API está descrito en el documento jsr-120. En el pasado, este mecanismo ha sido utilizado con éxito para la implementación de LBS [GANG2004] MMS (Multimedia Messaging System) Gracias al aumento en la complejidad de la información manejada por los teléfonos celulares (música, imágenes, videos) SMS resulta muy limitado en la actualidad. Por esta razón se creó el estándar MMS con los mismos objetivos y estructura de SMS pero con una carga útil de aproximadamente 300kb (según las capacidades del dispositivo y los límites establecidos por el operador). Al igual que en SMS, existen funcionalidades de bajo nivel que permiten a las aplicaciones utilizar este sistema para el envío y recepción de datos. 32

33 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 3.3. WAP (Wireless Application Protocol) Proporciona las especificaciones para un entorno de aplicaciones y una pila de protocolos que pretenden estandarizar la forma como los dispositivos móviles acceden a contenido de Internet, como correo electrónico y grupos de noticias. Su definición no especifica un protocolo para la capa de transporte pero se implementa casi siempre sobre SMS o GPRS. Un navegador WAP provee todos los servicios básicos que proporciona un navegador WEB pero simplificados para operar con recursos limitados. WAP Push permite hacer uso de mensajes SMS o de paquetes enviados por GPRS para enviar un link a otro servicio WAP y descargar datos adicionales BlackBerry Push Se trata de un servicio que permite al Servidor enviar datos al Cliente de forma asincrónica (Push) sin hacer uso de ninguna conexión específica. Es muy eficiente porque utiliza una infraestructura basada en un hardware especial presente en los teléfonos y que los operadores deben estar preparados para soportar. Los servicios BlackBerry mail y Black- Berry Messenger que han dado fama a estos dispositivos están construidos utilizando esta tecnología. Infortunadamente, este servicio solo funciona en teléfonos BlackBerry; el operador debe realizar cambios en su infraestructura para soportarlo y el usuario tiene que pagar por él IP (Internet Protocol) A partir de GPRS existe la posibilidad de enviar datagramas IP tanto en UDP como en TCP. Sin embargo, el envío y recepción de paquetes UDP por parte de teléfonos celulares se encuentra frecuentemente restringido por los operadores de telefonía celular para evitar el tráfico no autorizado de VOIP (Voz por IP). Las aplicaciones tienen acceso a la capa de transporte por medio de las funcionalidades de bajo nivel proporcionadas en el API de cada plataforma. En el caso de Java ME, este API está descrito en el documento jsr Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 33

34 Ingeniería de Sistemas Istar CIS0830-IS13 III - PROCESO 1. Metodología Propuesta En la propuesta original del presente Trabajo de Grado se planteó la siguiente metodología: I. Exploración Previa Durante esta etapa, se recopilará y clasificará información acerca de las diferentes plataformas existentes para dispositivos móviles. II. Análisis Con los datos recopilados, se analizarán las plataformas disponibles más utilizadas; sus fortalezas y debilidades en cuanto a la implementación de LBS. III. Diseño de la Propuesta Se hallará un subconjunto de funcionalidades de bajo nivel comunes en las plataformas analizadas (manejo de puertos, interfaz con el hardware, etc.). Dichas funcionalidades se utilizarán para realizar una propuesta que permita implementar LBS de tipo pull, push y tracking. IV. Diseño de la Arquitectura Se diseñará una arquitectura acorde con la propuesta, de tal forma que proporcione todas las funcionalidades extraídas en la fase anterior. Asimismo, se diseñará un LBS básico que requiera para su implementación la utilización de las funcionalidades pull, push y tracking, con el fin de probar la arquitectura a medida que es implementada. V. Implementación Se realizará la codificación del software asociado a la arquitectura, paralelamente se desarrollará el LBS básico anteriormente descrito para validar las funcionalidades de forma incremental. 34

35 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 2. Desarrollo del Proyecto Durante el desarrollo del proyecto, la metodología propuesta resultó ser adecuada en las tres primeras fases. Las fases IV y V se llevaron a cabo de forma ligeramente diferente. A continuación se expondrá el trabajo realizado en cada una de las fases metodológicas. I. Exploración previa Durante esta fase de desarrollo fueron exploradas las plataformas para dispositivos móviles y su relevancia actual en el mercado. Las plataformas consideradas fueron Apple iphone OS, Google Android, RIM Blackberry OS, Microsoft Windows Mobile, y Symbian OS. El marco teórico se complementó con los estándares de comunicación móvil que trabajan con las plataformas anteriormente mencionadas: GSM, CDMA, GPRS, EDGE, UMTS y HSDPA. II. Análisis Esta fase se centró en analizar cada plataforma para averiguar las facilidades que proporciona al desarrollador para acceder a las funcionalidades de bajo nivel que son necesarias para la implementación de servicios LBS de tipo pull, push y tracking. Se consideró importante también la capacidad para ejecutar aplicaciones concurrentemente así como varios hilos en cada aplicación. En todas menos una de las plataformas consideradas (Apple iphone OS) dichas funcionalidades son fácilmente utilizables por el desarrollador. III. Diseño de la propuesta Tras analizar las funcionalidades de red de bajo nivel que otorga cada plataforma al momento de implementar aplicaciones, se observó que todas permiten establecer conexiones TCP por medio de sockets. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 35

36 Ingeniería de Sistemas Istar CIS0830-IS13 Un socket TCP otorga: Comunicación full-dúplex. Envío y recepción de datos de forma asincrónica. Las plataformas analizadas permiten la ejecución de varios hilos. Gracias a esto, puede implementarse un mecanismo de espera para eventos asincrónicos. La capacidad para enviar datos asincrónicamente permite la implementación de operaciones de tipo pull. La posibilidad de recibir eventos asincrónicos es la base para realizar operaciones de tipo push. Las operaciones de tracking pueden implementarse al combinar operaciones pull y push, como se examinará detenidamente más adelante. En este punto de la metodología se concluyó que al considerar la información de posición proveniente de un GPS o de cualquier otro LCS como un parámetro, entonces un sistema que permita operaciones pull y push también permite la implementación de LBS de tipo pull, push y tracking. Esta conclusión será analizada con más detalle en la sección de resultados De esta forma, se plantea una respuesta a la pregunta que motivó el presente Trabajo de Grado: Cómo lograr la implementación de servicios genéricos para dispositivos móviles de tal forma que se utilicen eficientemente los recursos y sean independientes de la plataforma de cada dispositivo? R. Por medio de un Middleware que permita la definición e implementación de servicios genéricos de tipo pull push y tracking independientes de la plataforma orientado a dispositivos móviles. Con esta respuesta se procedió a diseñar el middleware y su protocolo asociado, descritos en el anexo 1. 36

37 Pontificia Universidad Javeriana Memoria de Trabajo de Grado IV. Diseño de la arquitectura Dentro de los objetivos de este Trabajo de Grado se encuentra la implementación de una aplicación de prueba para verificar la validez de la solución propuesta. Como resultado del paso metodológico III: Diseño de la propuesta, se obtuvo el documento que especifica un middleware (Anexo 1). Durante esta fase, se tomó dicho documento y se utilizó para diseñar una arquitectura para ser implementada en el paso metodológico V. Es importante aclarar que la arquitectura que se diseñó no está especificada en el documento de definición del middleware. Cualquier desarrollador que desee implementarlo es libre para diseñar su propia arquitectura, siempre y cuando su comportamiento se ajuste a lo especificado en el documento. La arquitectura diseñada está descrita en el anexo 2. V. Implementación El middleware fue implementado con base en la arquitectura diseñada en el paso IV en Java ME y Java SE haciendo uso de la metodología de desarrollo de software conocida como Prototipo Incremental. Dicha implementación se ejecutó satisfactoriamente en un computador de escritorio y en los dispositivos móviles RIM Blackberry 8100 y HTC Google Android G1. El middleware fue probado utilizando las tecnologías EDGE, WiFi y Ethernet (concurrentemente), con resultados igualmente positivos. Una vez probado el middleware, éste se utilizó para diseñar un servicio que requiere la utilización de las funcionalidades Pull, Push y Tracking necesarias para cumplir con los objetivos de este Trabajo de Grado. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 37

38 Ingeniería de Sistemas Istar CIS0830-IS13 3. Reflexión metodológica Como se mencionó anteriormente, la metodología propuesta fue apropiada para el desarrollo del proyecto durante las fases I, II y III. En las fases IV y V se introdujeron cambios para ajustarlas a las necesidades según el contexto, los cuales se exponen a continuación: IV. Diseño de la arquitectura a) Propuesta metodológica original Se diseñará una arquitectura acorde con la propuesta, de tal forma que proporcione todas las funcionalidades extraídas en la fase anterior. Asimismo, se diseñará un LBS básico que requiera para su implementación la utilización de las funcionalidades Pull, Push y Tracking con el fin de probar la arquitectura a medida que es implementada. b) Ejecución ajustada Se diseñó una arquitectura con la propuesta, de tal forma que proporcionaba todas las funcionalidades extraídas en la fase anterior. Se aplazó el diseño del servicio LBS de prueba para la fase de implementación. c) Justificación Se consideró que el servicio de prueba era completamente independiente de la arquitectura; su única función era validarla cuando ya se encontrara implementada. Por esta razón su especificación correspondía a la fase de pruebas. 38

39 Pontificia Universidad Javeriana Memoria de Trabajo de Grado V. Implementación d) Propuesta metodológica original Se realizará la codificación del software asociado a la arquitectura, paralelamente se desarrollará el LBS básico anteriormente descrito para validar las funcionalidades de forma incremental. e) Ejecución ajustada Se realizó la codificación del software asociado a la arquitectura. Las funcionalidades genéricas Pull y Push fueron implementadas sucesivamente. Una vez operativo el middleware, se utilizó para desarrollar servicios específicos para pruebas de rendimiento y un servicio de demostración. f) Justificación Diseñar previamente un servicio para ser desarrollado de forma paralela con el middleware añade las complejidades características de dicho servicio a la ya compleja implementación de la arquitectura. Se decidió entonces reducir el servicio a su mínima expresión: Las funcionalidades básicas Pull y Push. Una vez probadas, se puede diseñar e implementar cualquier servicio para validar y demostrar el middleware. El desempeño de los sockets TCP sobre la red de telefonía celular se desconocía. Por esta razón, el middleware desarrollado se empleó para implementar servicios de prueba que permitieron medir los valores de latencia y glitter de dicha tecnología. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 39

40 Ingeniería de Sistemas Istar CIS0830-IS13 Reflexión sobre la metodología Prototipo Incremental La metodología de desarrollo de software Prototipo Incremental resultó adecuada para el desarrollo del middleware, ya que permitió obtener prototipos funcionales desde el principio del proceso. Gracias a esto, varios problemas inherentes a la programación de dispositivos móviles emergieron en una etapa temprana y fueron solucionados primero. De esta forma se consiguió la separación entre los problemas técnicos y los bugs del middleware, lo cual facilitó enormemente el proceso de depuración. La principal desventaja consistió en la necesidad de refactorizar el código en sucesivas iteraciones, ya que para obtener prototipos funcionales de forma rápida fue necesaria la escritura de código provisional que más tarde tuvo que ser mejorado o reescrito, como es típico en Prototipo Incremental. Sin embargo, a partir de la experiencia con este trabajo, el desarrollador considera que el esfuerzo y tiempo invertidos en refactorizar el código no son comparables con el gran trabajo que habría supuesto la depuración de una gran cantidad de módulos complejos desarrollados por separado y probados en conjunto al final de la etapa de implementación. 40

41 Pontificia Universidad Javeriana Memoria de Trabajo de Grado IV - RESULTADOS En esta sección se consignan los resultados que fueron obtenidos durante el desarrollo de este Trabajo de Grado. El orden de aparición corresponde con el orden de ejecución. 1. Exploración sobre las plataformas para Dispositivos móviles 1.1. Plataformas más relevantes Las plataformas para dispositivos móviles que presentan mayor relevancia en la actualidad [MCCR2009], [YUNC2007] son: Google Android OS, RIM BlackBerry OS, Microsoft Windows Mobile, Symbian OS e iphone OS. A continuación un resumen de cada una desde el punto de vista del desarrollador de aplicaciones Google Android OS Se trata de un sistema operativo de código abierto desarrollado por Google que busca ser fácilmente adaptable a las necesidades de cada fabricante de dispositivos. El usuario puede interactuar con el sistema por medio de una pantalla sensible al tacto o un trackball. La base de este sistema es un kernel de Linux, que ejecuta a su vez varias máquinas virtuales Java para las aplicaciones del teléfono. Cada aplicación corre sobre su propia instancia de máquina virtual, y cada máquina virtual es un proceso en el sistema operativo. Sorprendentemente, esta plataforma no utiliza el estándar Java ME. Implementa la mayoría del estándar Java SE complementado con un API desarrollado especialmente para Android que permite al desarrollador un control muy profundo del sistema. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 41

42 Ingeniería de Sistemas Istar CIS0830-IS13 Android proporciona un emulador, un SDK, y un plugin de Eclipse para facilitar la implementación de aplicaciones. Las operaciones de depuración pueden realizarse en los dispositivos reales si así se desea e incluso existe un dispositivo especialmente diseñado para ello (Android Developer Phone) RIM BlackBerry OS Es el sistema operativo utilizado por todos los dispositivos BlackBerry fabricados por la compañía canadiense Research in Motion (RIM). Su interfaz ha cambiado muy poco en los últimos diez años, ya que siempre ha sido muy funcional, lógica y consistente. En la mayoría de los modelos, todas las operaciones se realizan gracias a un trackball, a un botón menu y un botón back. Las aplicaciones en esta plataforma se desarrollan utilizando Java ME. El programador tiene acceso a las funcionalidades de red de bajo nivel proporcionadas por dicho estándar además de un API para el manejo de la interfaz y las características particulares de estos dispositivos. RIM pone a disposición de los programadores un IDE propio, un plugin para Eclipse y un emulador para cada uno de sus dispositivos. El IDE puede enlazarse con un dispositivo real por medio del puerto USB para realizar la depuración paso a paso. 42

43 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Microsoft Windows Mobile Windows Mobile es la versión móvil del sistema operativo Windows. Intenta emular su interfaz al incluir un botón de inicio y una barra de tareas. Esto resulta poco práctico, ya que las pantallas reducidas pueden dificultar la visualización de íconos tan pequeños. El código de este sistema operativo es completamente cerrado. Sin embargo, los desarrolladores pueden utilizar el API.net Mobile y el entorno de desarrollo Visual Studio que es muy completo y permite el acceso a las funcionalidades de red de bajo nivel del dispositivo, aunque su licencia no es totalmente abierta. Esta plataforma ha perdido la gran popularidad que disfrutaba hace algunos años debido a las malas políticas de mercadeo de Microsoft [SEGA2009] Symbian Este sistema operativo es utilizado en dispositivos fabricados por Motorola, Nokia, Samsung, Siemens, y Sony Ericsson. Data de una época en la que toda la interfaz de usuario se reducía a un teclado alfanumérico y unos pocos botones adicionales. Las nuevas características como pantallas sensibles al tacto no están muy bien soportadas. Diseñado especialmente para procesadores ARM, su estructura está basada en un microkernel que contiene las unidades básicas del sistema operativo: planificador, administrador de memoria y drivers de dispositi- Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 43

44 Ingeniería de Sistemas Istar CIS0830-IS13 vo. Las aplicaciones pueden compilarse y ejecutarse en código de máquina, o correr en una máquina virtual de Java. El programador puede desarrollar aplicaciones para Symbian haciendo uso del compilador de C++ que está disponible de forma gratuita, o de un SDK para Java ME. Dependiendo del fabricante, existen diferentes emuladores para dispositivos que utilizan Symbian. Una aplicación implementada haciendo uso de cualquiera de estas herramientas tiene acceso a las funcionalidades de red de bajo nivel del dispositivo Apple iphone OS En la actualidad, solo los dispositivos iphone e ipod Touch utilizan este sistema operativo. Es una versión reducida de Mac OS con gran énfasis en gráficas 3D de alta velocidad, lo cual le permite soportar la pesada y compleja interfaz de usuario que utiliza casi exclusivamente una pantalla sensible al tacto y varios acelerómetros que pueden detectar cambios en la posición e inclinación del dispositivo. Uno de los principales objetivos de Apple al desarrollar este sistema es la velocidad de respuesta de las aplicaciones. Por esta razón todas deben ser compiladas a código de máquina y está expresamente prohibida la instalación de una máquina virtual (como la necesaria para ejecutar Java) o un compilador en tiempo de ejecución (como el utilizado por.net). Aunque el SDK se puede descargar gratis, el desarrollador debe pagar para obtener las firmas digitales que necesita para instalar su aplicación en un dispositivo real. (Existen modificaciones no autorizadas de hardware que permiten instalar aplicaciones no firmadas). Solo Apple puede desarrollar aplicaciones que se ejecuten concurrentemente, y el acceso a las funcionalidades de red de bajo nivel está muy limitado. 44

45 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 1.2. Resultado del estudio de las plataformas Después de estudiar cada plataforma, se obtuvieron los siguientes resultados considerados relevantes para este Trabajo de Grado: a) A excepción de Apple iphone OS, todas las plataformas proporcionan las herramientas y documentación necesarias para el desarrollo de aplicaciones de forma gratuita y abierta. b) RIM BlackBerry OS, Symbian OS soportan la tecnología Java ME, mientras que Google Android OS se basa en Java SE. c) A excepción de Apple iphone OS, todas las plataformas permiten que las aplicaciones desarrolladas tengan acceso a las funcionalidades de red de bajo nivel de los dispositivos. d) A excepción de Apple iphone OS, todas las plataformas permiten la ejecución concurrente de varias aplicaciones, al mismo tiempo que el uso de diferentes threads por cada aplicación. Teniendo en cuenta estos resultados, se concluye lo siguiente: a) El sistema operativo Apple iphone OS no se tendrá en cuenta a la hora de diseñar la solución, dado que las políticas de Apple no permiten el desarrollo de ninguna aplicación compleja por parte de terceros. b) La arquitectura diseñada se implementará en este Trabajo de Grado utilizando Java ME y Java SE, ya que de esta forma quedarán cubiertas las plataformas BlackBerry OS, Google Android OS y Symbian OS. c) La solución propuesta debe estar diseñada de tal forma que en trabajos futuros pueda ser implementada en plataformas diferentes a Java ME y Java SE. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 45

46 Ingeniería de Sistemas Istar CIS0830-IS13 2. Propuesta para la implementación de LBS En esta sección se exponen las funcionalidades básicas propuestas para la implementación de LBS en cada una de sus modalidades Propuesta de operaciones básicas en los LBS La solución a proponer debe tener la capacidad de implementar LBS en todas sus modalidades (Marco Teórico, secc. 2.1) o en cualquier combinación de las mismas. Para este propósito se halló un conjunto de operaciones básicas que ejecutadas en un determinado orden exhiben el comportamiento descrito. Este Trabajo de Grado propone dos operaciones básicas genéricas: Invocación de Método Remoto y Generación de Evento Asincrónico Invocación de Método Remoto (Pull) La ejecución de un método remoto se desencadena cuando es solicitada por el Cliente. De esta forma, una aplicación decide cuando los servicios son invocados. La Invocación de Método Remoto se subdivide en: El Cliente envía una solicitud compuesta por un nombre de método y una serie de parámetros. El Servidor ejecuta un método con los parámetros proporcionados y genera un resultado. El Servidor envía el resultado al Cliente. Si se produce un error al invocar un método, o si por alguna razón dicho método no se puede ejecutar, el resultado recibido por el cliente es una notificación de fallo (Excepción) Generación de Evento Asincrónico (Push) Un evento asincrónico es generado por el Servidor en el Cliente cuando ocurre un suceso que el Cliente está interesado en conocer. Se subdivide en: 46

47 Pontificia Universidad Javeriana Memoria de Trabajo de Grado El Servidor determina que ha ocurrido un suceso y un determinado Cliente debe ser informado. El Servidor envía una notificación al Cliente compuesta por un nombre de evento y una serie de parámetros. Un evento es asincrónico porque el Cliente no puede determinar con exactitud cuándo ocurrirá Implementación de los diferentes tipos de LBS por medio de Invocación de Método Remoto y Generación de Evento Asincrónico Una vez definidas las operaciones básicas Invocación de Método Remoto y Generación de Evento Asincrónico, se expone cómo estas pueden combinarse para implementar cada tipo de servicio LBS Implementación de LBS tipo Pull Según (Marco Teórico, secc. 2.1), existen dos subtipos de LBS de tipo Pull: a) Cuando el servicio Pull requiere la posición del solicitante: En este caso, el Cliente realiza una Invocación de Método Remoto y envía como parámetro su propia posición. Si dicha posición no se puede determinar o Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 47

48 Ingeniería de Sistemas Istar CIS0830-IS13 aproximar, el método no puede ser invocado. Si el método se ejecuta satisfactoriamente, el Servidor retorna al Cliente un resultado, si no, se retorna un error. b) El servicio Pull requiere la posición de otro dispositivo: El Cliente realiza una Invocación de Método Remoto. El Servidor necesita la posición de otro dispositivo para ejecutar el método. La posición de este tercer actor puede determinarse de dos formas: i. El Servidor interroga al cliente: El Servidor genera un Evento Asincrónico en un Cliente para notificarle que su posición es requerida. Seguidamente, el Cliente responde por medio de una Invocación de Método Remoto con su posición como parámetro. 48

49 Pontificia Universidad Javeriana Memoria de Trabajo de Grado ii. El Cliente anuncia periódicamente su posición: Si resulta más eficiente debido a la naturaleza del servicio que se está implementando, un Cliente podría realizar una Invocación de Método Remoto en forma regular para indicar al Servidor su posición actual o un cambio en la misma. Así, cuando el Servidor requiere una posición determinada consulta el registro de posiciones más actualizado en vez de interrogar a los dispositivos. Si no puede hallarse la posición, el método no puede ejecutarse y el Servidor retorna un error Implementación de LBS tipo Push El Servidor utiliza una Generación de Evento Asincrónico en el Cliente con una serie de parámetros para notificar que cierto suceso ha ocurrido Implementación de LBS tipo Tracking En un LBS de tipo Tracking, se utiliza un reporte periódico de la posición de un dispositivo móvil en particular para trazar una ruta en el tiempo. Esto puede lograrse uti- Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 49

50 Ingeniería de Sistemas Istar CIS0830-IS13 lizando una combinación de Invocación de Método Remoto y Generación de Evento Asincrónico, así: a) Los dispositivos que están siendo monitoreados realizan una Invocación de Método Remoto para indicar su posición periódicamente o lo hacen para indicar un cambio en la misma. b) Los Clientes interesados en conocer la posición de otro u otros dispositivos en tiempo real reciben Eventos Asincrónicos desde el Servidor cada vez que está disponible nueva información de posición de los dispositivos monitoreados. El tiempo real se encuentra limitado por las propiedades de latencia y glitter de la red que se utilice para la transmisión de los datos La información de posición como parámetro En los LBS, se conoce como información de posición al conjunto de datos que permite ubicar un punto sobre el planeta de forma unívoca. Dependiendo del LCS que se esté utilizando, esta información puede estar complementada con datos como orientación, velocidad y altura sobre la superficie. En todo caso, la información de posición consistirá en una tupla de datos de algún tipo, muy probablemente numérico. Esta tupla puede considerarse como un parámetro (o una serie de parámetros) que puede ser enviado al realizar una Invocación de Método Remoto o una Generación de Evento Asincrónico. Es importante recalcar que: una Invocación a Método Remoto o una Generación de Evento Asincrónico no necesariamente requiere de la información de posición para llevarse a cabo. Como ejemplo, el Cliente puede interrogar al Servidor acerca del valor de una acción en determinado momento. O el Servidor puede notificar asincrónicamente a un Cliente que una acción a alcanzado un valor crítico y debe vender. Ninguno de estas operaciones requiere la información de posición. 50

51 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 2.4. Resultados del estudio sobre la implementación de LBS Después de estudiar los diferentes tipos de LBS y su implementación, se obtuvieron los siguientes resultados considerados relevantes para este Trabajo de Grado: a) Las operaciones básicas Invocación de Método Remoto y Generación de Evento Asincrónico son suficientes para la implementación de un LBS en cualquiera de sus modalidades. b) La información de posición puede considerarse como un parámetro más al momento de ejecutar cualquiera de las operaciones básicas. Teniendo en cuenta estos resultados, se concluye lo siguiente: a) Si la solución incluye un mecanismo para la implementación de las operaciones básicas Invocación de Método Remoto y Generación de Evento Asincrónico, entonces tendrá la capacidad para implementar cualquier LBS y cumplir así con el principal objetivo del presente Trabajo de Grado. b) Si la solución puede utilizarse para implementar cualquier LBS, entonces también podrá emplearse para implementar servicios que no sean LBS, es decir, que no requieran de la información de posición para su funcionamiento. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 51

52 Ingeniería de Sistemas Istar CIS0830-IS13 3. Estudio de las características técnicas de la Solución Con los resultados obtenidos anteriormente, se procedió a hallar las características técnicas más adecuadas para una solución que permita la implementación de las operaciones básicas Invocación a Método Remoto y Generación de Evento Asincrónico Comparación entre los diferentes mecanismos de transferencia de datos En (fig. 9) se comparan los diferentes mecanismos para la transferencia de datos entre dispositivos móviles (Marco Teórico secc. 3) por medio de la siguiente lista de criterios: Disponibilidad: El mecanismo está disponible en una gran variedad de dispositivos móviles. Interoperabilidad: Las diferentes plataformas lo implementan, por esto pueden utilizarlo para interactuar entre ellas. Capacidad de Pull: Tiene el potencial para implementar la operación básica Invocación de Método Remoto anteriormente definida. Capacidad de Push: Tiene el potencial para implementar la operación básica Generación de Método Asincrónico anteriormente definida. Latencia: El tiempo que le toma al Cliente enviar un mensaje al Servidor y viceversa. Ancho de banda: El tamaño de los parámetros que pueden enviarse del Cliente al Servidor y viceversa. 52

53 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 1) Solo está disponible en las redes de telefonía celular; para interactuar con Internet se requieren adaptadores. 2) WAP puede visualizar contenido de Internet, pero necesita un adaptador intermedio que interprete y transforme los datos. 3) La definición de Invocación de Método Remoto requiere la capacidad de generar un retorno como parte de la misma transacción. En este caso es necesario generar un Evento Asincrónico aparte para enviar al Cliente el resultado de la invocación. 4) La latencia depende mucho de la configuración del operador y la congestión actual de la red. Puede ser de algunos segundos, y en ocasiones, minutos. 5) Entre 800ms y 2000ms. 6) [ARZU2008] 500ms-2000ms, GPRS; 500ms-1000ms, EDGE; ~200ms, UMTS; ~100ms, HSDPA. 7) GPRS es práctico hasta ~500kb, dependiendo de la configuración del operador y la cobertura. EDGE, UMTS son útiles hasta decenas de Mb (Sin embargo, un dispositivo móvil en general no descarga o envía archivos de ese tamaño). HSDPA puede manejar voz y video en tiempo real. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 53

54 Ingeniería de Sistemas Istar CIS0830-IS Resultados de la comparación entre los diferentes mecanismos de transferencia de datos para dispositivos móviles Después de estudiar y comparar los diferentes mecanismos de transferencia de datos disponibles para dispositivos móviles, se llegó a los siguientes resultados, considerados relevantes para el presente Trabajo de Grado: a) Los sistemas SMS, MMS y WAP han sido utilizados satisfactoriamente en el pasado para la construcción de LBS, y tienen el potencial para la implementación de las operaciones básicas Invocación de Método Remoto y Generación de Evento Asincrónico. b) Los sistemas SMS, MMS, y WAP son prácticamente universales, todas las plataformas para dispositivos móviles soportan los protocolos estandarizados. c) Los sistemas SMS, MMS, y WAP están estrechamente ligados con las redes de telefonía celular, y no hacen parte de la pila de protocolos de IP. d) La latencia de los sistemas SMS, MMS y WAP tiende a ser muy alta e impredecible. e) El sistema BlackBerry Push es muy eficiente, pero solo está disponible para dispositivos BlackBerry y es necesario pagar por su utilización. f) Los protocolos TCP/IP y UDP/IP están soportados por las tecnologías GPRS, EDGE, UMTS, HSDPA. g) El protocolo UDP es de uso restringido en muchas redes de telefonía celular. Teniendo en cuenta estos resultados, se concluye lo siguiente: a) A pesar de su universalidad, los sistemas de transferencia de datos SMS, MMS y WAP no se utilizarán para diseñar la solución, ya que su interoperabilidad con Internet necesita desarrollos adicionales y su latencia es muy alta. b) El protocolo UDP/IP es muy eficiente pero será descartado, ya que los operadores de redes celulares restringen su uso. c) El protocolo TCP/IP será el utilizado para el diseño de la solución en este Trabajo de Grado. 54

55 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 3.3. Formato de datos Es necesario establecer el formato que se utilizará a la hora de transmitir los datos utilizando el protocolo seleccionado (TCP/IP). Para esto existen dos posibilidades: transferencia binaria y transferencia de texto Transferencia binaria La carga útil consiste en un arreglo de bytes. Es muy eficiente, ya que un solo byte proporciona 255 estados u 8 banderas, lo cual permite enviar toda la información del sistema (tipo de comando, errores, etc.) utilizando unos pocos bytes. La eficiencia también se manifiesta durante la transferencia de los parámetros. Por ejemplo, un entero desde hasta puede representarse en forma binaria con solo 4 bytes. Sin embargo, la trama resultante resulta ilegible para un humano y su implementación muy estricta; basada en las posiciones de los bytes de tal forma que es difícil introducir cambios posteriores. Algunas combinaciones de bits corresponden a caracteres especiales que pueden ser interpretados de diferentes formas por diferentes sistemas generando errores en la transmisión y dificultades de interoperabilidad Transferencia de texto Los datos se transfieren de forma alfanumérica. Por ejemplo, el entero se transmite como (10 bytes). En forma binaria se transmitiría como = zƒ ç (4 bytes). Los comandos e indicadores del sistema también deben ser representados por varios caracteres, lo cual aumenta el tamaño de la trama. Al transmitir de esta forma puede hacerse uso del formato XML que evita la presencia de caracteres especiales y por lo tanto los potenciales problemas de interoperabilidad, al mismo tiempo que las tramas se hacen legibles para los humanos facilitando así el trabajo de depuración. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 55

56 Ingeniería de Sistemas Istar CIS0830-IS Resultados del estudio de los posibles formatos de datos Después de estudiar los formatos de transferencia binario y de texto, se concluye lo siguiente: a) El formato de transferencia binaria no se utilizará dados los posibles problemas de interoperabilidad y su inflexibilidad a la hora de introducir cambios posteriores. b) La solución utilizará el formato de transferencia de texto y el Lenguaje de Marcas Extensible (XML) porque de esta forma se alcanza el objetivo de Interoperabilidad en el presente Trabajo de Grado. 56

57 Pontificia Universidad Javeriana Memoria de Trabajo de Grado 4. Propuesta de Solución Una vez halladas las características generales que debe implementar la Solución, se procede a diseñar una propuesta para la misma Compilación de las características de la Solución En las secciones anteriores se hallaron las características que debe tener la Solución propuesta para satisfacer todos los objetivos del presente Trabajo de Grado. Estas características son: a) La solución debe ser implementable en todas las plataformas estudiadas a excepción de Apple iphone OS. b) La solución debe tener la capacidad de realizar las operaciones básicas Invocación de Método Remoto y Generación de Evento asincrónico tal como fueron definidas en la sección (Resultados, secc. 2.2.) de este documento. c) La solución debe utilizar el protocolo TCP/IP para el transporte de datos. d) Los datos serán transmitidos en formato texto por medio del Lenguaje de Marcas Extensible XML El Middleware OMNI Para satisfacer las características anteriormente mencionadas se inició un proyecto de desarrollo de software cuyo objetivo es la especificación y desarrollo de un Middleware para la implementación de servicios genéricos orientado a dispositivos móviles. A tal proyecto y a su Middleware asociado se les dio el nombre de OMNI. El documento de especificación tiene como fin dar a los desarrolladores toda la información necesaria para implementar el Middleware en una plataforma determinada de tal forma que pueda interactuar con otras implementaciones del mismo. Por esta razón, la especificación del Middleware es completamente independiente de la plataforma. Este documento puede encontrarse en el anexo 1. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 57

58 Ingeniería de Sistemas Istar CIS0830-IS13 Se expondrá a continuación de manera global la estructura y funcionamiento del Middleware OMNI El Redirector y el Servidor OMNI La estructura de un servicio OMNI contempla dos servidores: el Redirector OMNI, que actúa como un registro y el Servidor OMNI, en donde se encuentra el servicio propiamente dicho. Los Clientes conocen la IP o el host del Redirector; se conectarán a él para averiguar el host del Servidor OMNI que aloja el servicio deseado. (fig. 10) Sesión OMNI Cuando un Cliente ha obtenido la dirección IP o el host del Servidor OMNI, establece una conexión y negocia una sesión. Esta sesión se desarrolla sobre una conexión TCP full-dúplex que se mantiene abierta mientras dure la sesión y se multiplexa para enviar las solicitudes de Ejecución de Método Remoto y recibir las notificaciones de Evento Asincrónico al mismo tiempo. El Middleware envía además otras tramas para control interno, pero de forma transparente para la aplicación. 58

59 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Al momento de iniciar sesión, el Cliente debe declarar qué tipo de dispositivo intenta conectarse. Esto podría utilizarse en un futuro con fines estadísticos o para dar trato preferencial a ciertos dispositivos según su tipo: Desktop: Computador de escritorio o portátil. SmartPhone: Teléfono celular con capacidades superiores. HandHeld: Computador de bolsillo. LimitedPhone: Teléfono celular con capacidades muy inferiores. EmbeddedDevice: Dispositivo embebido. (máquinas, sistemas de rastreo, sistemas basados en microcontroladores en general). CriticalDevice: Dispositivo utilizado para el monitoreo de pacientes a distancia, sistemas de de seguridad, aplicaciones para la bolsa de valores. ExperimentalDevice: Dispositivo experimental o en desarrollo. Seguidamente, el Cliente recibe una cadena de caracteres de hasta 128 bytes correspondiente al valor de la variable de sistema connectionid. Esta variable identifica unívocamente la sesión Tipos de datos en OMNI La versión del Middleware que será entregada soporta los siguientes tipos básicos de dato: Entero con signo de 32 bits, (int). Real con signo, (double). Booleano, (boolean). Cadena de caracteres (string). Arreglos de los tipos de datos anteriores.(int[], double[], etc.). Internamente se utilizan los tipos Estructura de datos y Arreglo recursivo. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 59

60 Ingeniería de Sistemas Istar CIS0830-IS Excepciones OMNI El Middleware define dos clases de excepciones: Excepciones de Sistema y Excepciones de Servicio. Una Excepción de Sistema se lanza cuando el error que ha ocurrido ha sido generado por la conexión o por el Middleware. Una Excepción de Servicio ocurre cuando un Método Remoto invocado genera una excepción. Existe una lista de las posibles Excepciones de Sistema (presente en la defininición del Middleware), mientras que el programador de un Servicio es libre de diseñar sus propias Excepciones de Servicio definiéndolas así: a) Un número entero (int) que identifica la excepción. b) Una cadena de caracteres (String) que describe la excepción. El desarrollador puede definir cualquier número (32 bytes) de Excepciones de Servicio Servicios OMNI Un servicio en OMNI se define como: Una interfaz implementada por el Cliente con una serie de Eventos Asincrónicos. Una interfaz implementada por el Servidor con una serie de Métodos Remotos que retornan un valor o lanzan una Excepción de Servicio. Una interfaz implementada por el Servidor con una serie de Eventos Asincrónicos. Un nombre de servicio. 60

61 Pontificia Universidad Javeriana Memoria de Trabajo de Grado En (fig. 11) puede verse un ejemplo de la Interfaz de Eventos Asincrónicos del lado del Cliente en un hipotético servicio de Chat, tal como se vería al utilizar el Middleware en Java ME que se entrega como parte de este Trabajo de Grado: Figura 11. (Ejemplo de interfaz OMNI para el Servidor) import co.edu.javeriana.lbs.omni.io.connectionexception; import co.edu.javeriana.lbs.omni.service.pushlistener; public interface chatpushlistener extends PushListener { public void mensajerecibido(string remitente, String mensaje) throws ConnectionException; public void UsuarioCerca(int id, double longitud, double latitud) throws ConnectionException; public void usuarioconectado(string nombreusuario, int id) throws ConnectionException; } En (fig. 12) puede verse un ejemplo de la interfaz de Métodos Remotos y Eventos Asincrónicos que implementaría el Servidor en un hipotético servicio de Chat. Figura 12. (Ejemplo de interfaz OMNI para el Cliente) import co.edu.javeriana.lbs.omni.io.connectionexception; import co.edu.javeriana.lbs.omni.service.pullservices; public interface chatpullservices extends PullServices { //Eventos asincronicos: public void actualizarposicion(int id, double longitud, double latitud) throws ConnectionException; public void enviarmensaje(int idremitente, int iddestino, String mensaje) throws ConnectionException; //Metodos remotos: public String[] getlistacontactos() throws ConnectionException; public double[] getposicionusuario(int idusuarioubicar) throws ConnectionException; } Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 61

62 Ingeniería de Sistemas Istar CIS0830-IS OMNI Middleware Protocol El protocolo utilizado por el Middleware OMNI está basado en el estándar XML-RPC [WINE2003] y añade al mismo la capacidad de enviar eventos asincrónicos del Servidor al Cliente. Su especificación puede encontrarse en el anexo 1. Se proporcionan a continuación ejemplos de las tramas utilizadas durante su operación. Figura 13, Generación de evento Asincrónico. <?xml version="1.0"?> <generateevent> <eventname>chat.push.event.usuariocerca</eventname> <params> <param> <value> <array> <data> <value><int>65432</int></value> <value><double> </double></value> <value><string> </string></value> </data> </array> </value> </param> </params> </generateevent> En (fig. 13) se muestra un ejemplo de la trama enviada por el Servidor para generar Eventos Asincrónicos en el Cliente para un servicio hipotético de Chat. 62

63 Pontificia Universidad Javeriana Memoria de Trabajo de Grado (fig. 14) presenta un ejemplo de la trama enviada por el Cliente al Servidor para solicitar la ejecución de un Método Remoto y las posibles respuestas del Servidor (Valor de Retorno o Excepción) en un servicio hipotético de Chat. -Invocación del Cliente: Figura 14 Invocación de Método Remoto. <?xml version="1.0"?> <methodcall> <methodname>chat.pull.method.getposicionusuario</methodname> <params> <param> <value> <array><data> <value><int>6545</int></value> </data></array> </value> </param> </params> </methodcall> -Respuesta del Servidor (Éxito): <?xml version="1.0"?> <methodresponse> <params> <param> <value> <array><data> <value><double> </double></value> <value><double> </double></value> </data></array> </param> </params> </methodresponse> -Respuesta del Servidor (Fallo): <?xml version="1.0"?> <methodresponse> <fault> <value> <struct> <member> <name>faultcode</name> <value><int>0</int></value> </member> <member> <name>faultstring</name> <value><string>the service has generated an exception.</string></value> </member> <member> <name>serviceerrorcode</name> <value><int>5</int></value> </member> <member> <name>serviceerrordescription</name> <value><string>el USUARIO NO EXISTE!</string></value> </member> </struct> </value> </fault> </methodresponse> Página 63 Preparado por el Grupo Investigación Istar- Versión /03/2008

64 Ingeniería de Sistemas Istar CIS0830-IS13 5. Implementación Tras definir una solución, el siguiente paso consiste en validar su funcionalidad. Con este fin se diseñó una arquitectura adecuada para la implementación del Middleware OMNI en Java ME y Java SE tal como se especifica en (Resultados secc. 1.2). La arquitectura puede consultarse en el anexo 2; la documentación en el anexo Arquitectura OMNI es un Middleware basado en una arquitectura Cliente-Servidor. Se trata de una capa que sirve de intermediario entre la aplicación y la capa de transporte, de forma que el flujo de datos codificados en XML a través de la red es completamente transparente para las implementaciones del Cliente y del Servidor Componentes La arquitectura comprende seis componentes principales: Redirector OMNI, Servidor OMNI, Cliente OMNI, Generador de Stubs, Parser XML y Módulo de Compatibilidad. 64

65 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Redirector OMNI Se trata de un servidor que espera continuamente la conexión de Clientes OMNI para redireccionarlos al servidor que presta el servicio solicitado. El puerto por el cual se realiza la conexión no se especifica; el administrador puede escoger la configuración que más le convenga. Es la puerta de entrada a los Servicios OMNI. Cuando una aplicación desea acceder a un servicio, se conecta con el Redirector para obtener su dirección IP o host. El redirector puede utilizarse para realizar balanceo de carga u operaciones de mantenimiento en los servidores que prestan el Servicio OMNI Servidor OMNI Este servidor tiene la capacidad de manejar concurrentemente la sesión OMNI de un cierto número de Clientes OMNI (dependiendo de la configuración y las capacidades de la máquina). El puerto por el cual se realiza la conexión no está especificado. Una vez obtenido el host, el Cliente se conecta con el Servidor OMNI e inicia una sesión. A partir de ese momento, puede invocar los Métodos Remotos o recibir los Eventos asincrónicos que hacen parte del Servicio. El Servidor puede a su vez servir como puente para otros sistemas, como invocación SOAP o webservices Cliente OMNI El Cliente OMNI es la parte del Middleware presente en el Cliente, entre la aplicación y la capa de transporte. Se encarga de la transmisión y recepción de datos de tal forma que resulte transparente para la aplicación. De forma transparente para la aplicación, realiza operaciones orientadas a la conservación y restablecimiento de la conexión con el Servidor OMNI: PING: El Cliente envía un paquete al Servidor cuando ha transcurrido cierto tiempo (determinado por la configuración) sin que se le haya no- Página 65 Preparado por el Grupo Investigación Istar- Versión /03/2008

66 Ingeniería de Sistemas Istar CIS0830-IS13 tificado un Evento Asincrónico o haya recibido un Retorno de Método. De esta forma, puede verificarse si la conexión continúa abierta. Restablecimiento de conexión: Si por alguna razón la conexión se pierde, el Cliente intentará restablecerla y continuar con la sesión. Si tras cierto número de intentos (determinado por la configuración) esto no es posible, la Aplicación cliente será notificada Generador de Stubs Por tratarse de un Middleware orientado a dispositivos móviles, los Stubs en OMNI se generan en tiempo de compilación. De esta forma, se elimina la carga computacional derivada de los Stubs generados en tiempo de ejecución. Para facilitar el proceso de desarrollo en Java ME y Java SE, se incluyó un módulo generador de código que toma los archivos.java correspondientes a las interfaces del Cliente y del Servidor y genera automáticamente el código en Java compilable correspondiente al Stub de Cliente y el Stub de Servidor (Skeleton) Parser XML El Parser de XML fue implementado cuidadosamente; trabaja sobre una única copia de la cadena XML en memoria. Fue diseñado para ser ejecutado en dispositivos con memoria y recursos computacionales limitados. Tiene la capacidad de hallar errores en la sintaxis y en la estructura de la cadena XML que analiza. 66

67 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Módulo de Compatibilidad El Módulo de Compatibilidad es la única diferencia entre las implementaciones en Java ME y Java SE. Está diseñado para encapsular las diferencias en el establecimiento y manejo de conexiones TCP que existen entre estas dos versiones de Java y proporcionar una interfaz común. Por condiciones de hardware, algunos dispositivos móviles presentan particularidades en el manejo de conexiones TCP aún cuando afirmen apegarse al estándar Java ME. Para portar el Middleware a estos dispositivos basta con reescribir el Módulo de Compatibilidad y respetar su interfaz, ya que el resto está desarrollado en Java estándar Implementación de Servicios con OMNI Para desarrollar Servicios haciendo uso del Middleware OMNI se deben seguir los siguientes pasos generales: i. Definición de la Interfaz de Eventos Asincrónicos que el cliente implementará. ii. Definición de la Interfaz de Métodos Remotos y Eventos Asincrónicos que el Servidor implementará. iii. Creación de Stubs para el Cliente y el Servidor por medio del Generador Automático de Stubs. iv. Implementación o adaptación de la lógica del Servicio según las interfaces que se han definido. v. Desarrollo de la aplicación en el Cliente. Debe implementar la Interfaz de Eventos Asincrónicos a través de la cual el Stub de Cliente le notificará de tales eventos. Asimismo, la aplicación invocará los Métodos Remotos a través de la Interfaz de Métodos Remotos que implementa dicho Stub. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 67

68 Ingeniería de Sistemas Istar CIS0830-IS Aplicaciones del Middleware OMNI Dadas sus características, el Middleware OMNI puede utilizarse para implementar gran cantidad de servicios que involucran dispositivos móviles. Ejemplos de aplicaciones posibles en OMNI son: LBS: de tipo Pull, Push y Tracking. Telemetría: Gracias a su capacidad para recibir eventos asincrónicos, el Cliente recibe información de telemetría en tiempo real con una latencia conocida. Telecontrol: El sistema invoca métodos remotos para controlar dispositivos o máquinas distantes. Monitoreo de pacientes a distancia: El sistema recibe un reporte periódico o en tiempo real de ciertos signos vitales medidos en un paciente. 68

69 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Domótica: El usuario está al tanto de los eventos de su casa inteligente, al mismo tiempo que la controla a distancia. Sistemas de alarma: El usuario puede ser notificado cuando una alarma se ha activado. Sistemas de monitoreo económico: El Cliente conoce los valores de las acciones en tiempo real o simplemente es alertado cuando una acción sobrepasa cierto umbral. Redes sociales: El usuario es alertado cuando sus amigos se encuentran físicamente cerca de él. Pueden organizarse rápidamente concentraciones en un punto determinado por el sistema como el de más fácil acceso para todos los usuarios interesados en la reunión. Juegos: El Usuario tiene la capacidad de jugar con otros usuarios distantes. Monitoreo de unidades: Una empresa puede conocer donde se encuentran todas sus unidades para determinar cuál está más cerca de un determinado punto y puede prestar un servicio más rápidamente. Recuperación de vehículos robados: Un Cliente puede seguir en un mapa la trayectoria de su vehículo robado. Recolección de datos sobre rutas: Una serie de dispositivos instalados en vehículos pueden transmitir la información de las rutas que recorren para complementar el mapa de una ciudad, así como la velocidad promedio, el tiempo de espera en semáforos, etc. Correo electrónico: Los correos electrónicos se redirigen instantáneamente al dispositivo móvil; pueden ser leídos y contestados. Comercio electrónico: El usuario puede comprar y vender, es notificado cuando las subastas comienzan o terminan; cuando se publica cierto artículo con cierto precio, cuando algo se vende o se compra, etc. Acceso simplificado a sistemas más complejos: Las aplicaciones pueden acceder a los servicios disponibles en SOAP, CORBA, etc. de forma simplificada a través de OMNI. El Cliente envía los parámetros y el Servidor se encarga de invocar los servicios y reenviar sus resultados de vuelta al Cliente. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 69

70 Ingeniería de Sistemas Istar CIS0830-IS13 6. Pruebas Una vez finalizado el proceso de implementación y depuración del Middleware OMNI se realizaron pruebas para evaluar su rendimiento Latencia y Glitter En esta prueba, la Latencia se define como el tiempo que toma un mensaje en ir del Cliente al Servidor y regresar. En pocas palabras, realizar un PING. El Glitter es la desviación estándar de la Latencia. Para hallar estos valores, se diseñó e implementó un sencillo Servicio OMNI con la siguiente Interfaz de Métodos y Eventos Remotos en el Servidor: Figura 15. (Interfaz OMNI para el servidor PING) import co.edu.javeriana.lbs.omni.io.connectionexception; import co.edu.javeriana.lbs.omni.service.pullservices; public interface pingpullservices extends PullServices { public String pingfromclient(string load) throws ConnectionException; public void savedata(string filename, String info, int[] delays) throws ConnectionException; } Durante la prueba, el Cliente invoca el método String pingfromclient(string load) para enviar al Servidor una cadena arbitraria de cierta longitud. Seguidamente, el Servidor retorna al Cliente un String correspondiente a la cadena que se recibió. El Cliente mide el tiempo que transcurre entre la invocación y el retorno. Tras repetir este proceso 100 veces, el Cliente genera el Evento Remoto void savedata(string filename, String info, int[] delays) para enviar al Servidor los tiempos resultado de cada una de las 100 pruebas y guardarlos en un archivo. Se asumió que el tiempo que tarda el Servidor en generar el retorno es constante y cercano a cero. 70

71 Pontificia Universidad Javeriana Memoria de Trabajo de Grado La prueba se realizó con 11 longitudes diferentes de la cadena (carga útil). Los resultados pueden verse en (fig. 16) y (fig. 17). Los datos registrados en cada prueba pueden consultarse en el anexo 7. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 71

72 Ingeniería de Sistemas Istar CIS0830-IS13 Como puede apreciarse, hasta los 3500 bytes de carga útil la latencia y el glitter se mantienen dentro de los valores esperados para la tecnología que se está utilizando (3G). Después de ese valor, el glitter aumenta de tal forma que se hace muy difícil establecer un valor predecible para la latencia. Durante las pruebas se enviaron decenas de miles de paquetes a través de la conexión sin registrar nunca la pérdida de uno de ellos. Esto indica que el sistema es confiable Servicio de prueba chatlbs Finalmente, se utilizó el Middleware para la implementación de un servicio que explota las funcionalidades Pull, Push y Tracking de OMNI. El servicio chatlbs permite a los usuarios del sistema comunicarse entre sí por medio de mensajes, al mismo tiempo que visualiza la posición de cada uno de ellos en tiempo real (Limitado a la latencia del sistema). (fig. 18). El chatlbs puede representarse como un grafo completo, ya que cada usuario conoce la posición de todos los demás. 72

73 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Este servicio es suficiente para validar las funcionalidades del Middleware porque: a) Cuando un usuario solicita el envío de un mensaje, se realiza una operación Pull. b) Cuando un usuario recibe un mensaje o una notificación de cambio de posición por parte de otro usuario, se realiza una operación Push. c) Cada usuario notifica sus cambios de posición al Servidor, el cual se encarga de registrarlos y repetirlos inmediatamente a todos los demás usuarios. Esto constituye un servicio de tipo Tracking. Para lograr las funcionalidades propuestas, se diseñaron las interfaces de Servidor y Cliente requeridas por el Middleware OMNI. (fig. 19) y (fig. 20). Figura 19. (Interfaz OMNI para el Servidor chatlbs) import co.edu.javeriana.lbs.omni.io.connectionexception; import co.edu.javeriana.lbs.omni.service.pullservices; public interface chatlbspullservices extends PullServices { public boolean iniciarsesion(string ID, String nombreusuario) throws ConnectionException; public boolean cerrarsesion(string ID) throws ConnectionException; public boolean enviarmensaje(string IDremitente, String nombredestino, String mensaje) throws ConnectionException; public void enviarmensajebroadcast(string IDremitente, String mensaje) public void throws ConnectionException; actualizarlocalizacion(string ID, double[] coordenadas) throws ConnectionException; public String[] getlistausuarios(string ID) throws ConnectionException; } iniciarsesion(string ID, String nombreusuario), cerrarsesion(string ID) y getlistausuarios(string ID) son los métodos que se emplean para entrar, salir y obtener la información inicial del sistema. Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 73

74 Ingeniería de Sistemas Istar CIS0830-IS13 enviarmensaje(string IDremitente, String nombredestino, String mensaje) y enviarmensajebroadcast(string IDremitente, String mensaje) son servicios Pull para enviar mensajes de texto. actualizarlocalizacion(string ID, double[] coordenadas) se invoca para informar al Servidor cuando la posición del dispositivo ha cambiado. Figura 20. (Interfaz OMNI para el Cliente chatlbs) import co.edu.javeriana.lbs.omni.io.connectionexception; import co.edu.javeriana.lbs.omni.service.pushlistener; public interface chatlbspushlistener extends PushListener { public void usuarioconectado(string nombreusuario) throws ConnectionException; public void usuariodesconectado(string nombreusuario) throws ConnectionException; public void posicionactualizada(string nombreusuario, double[] coordenadas) throws ConnectionException; public void mensajeprivadorecibido(string nombreremitente, String mensaje) throws ConnectionException; public void mensajebroadcastrecibido(string nombreremitente, String mensaje) throws ConnectionException; } usuarioconectado(string nombreusuario) y usuariodesconectado(string nombreusuario) son Eventos Asincrónicos (Push) que notifican al Cliente si un determinado usuario se ha conectado o desconectado. posicionactualizada(string nombreusuario, double[] coordenadas) es un Evento Asincrónico que notifica al Cliente del cambio en la posición de un usuario. mensajeprivadorecibido(string nombreremitente, String mensaje) y mensajebroadcastrecibido(string nombreremitente, String mensaje) son Eventos Asincrónicos que informan al Cliente de la recepción de un mensaje. 74

75 Pontificia Universidad Javeriana Memoria de Trabajo de Grado Tras su implementación, el servicio fue desplegado como puede verse en (fig. 21). Preparado por el Grupo Investigación Istar- Versión /03/2008 Página 75

76 Ingeniería de Sistemas Istar CIS0830-IS13 Unas capturas de pantalla en Windows y en BlackBerry OS pueden verse en (fig. 22). 76

CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES

CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES CIS0830-IS13 MIDDLEWARE PARA LA DEFINICIÓN E IMPLEMENTACIÓN DE SERVICIOS GENÉRICOS INDEPENDIENTES DE LA PLATAFORMA ORIENTADO A DISPOSITIVOS MÓVILES CÉSAR ESTÉBAN CASTAÑEDA RUÍZ PONTIFICIA UNIVERSIDAD JAVERIANA

Más detalles

TECNOLOGÍA 3G ACOSTA VENEGAS ALBERTO AGUILAR SALINAS GUILLERMO MIRANDA ELIZALDE CARLOS VENEGAS HURTADO JUAN

TECNOLOGÍA 3G ACOSTA VENEGAS ALBERTO AGUILAR SALINAS GUILLERMO MIRANDA ELIZALDE CARLOS VENEGAS HURTADO JUAN TECNOLOGÍA 3G ACOSTA VENEGAS ALBERTO AGUILAR SALINAS GUILLERMO MIRANDA ELIZALDE CARLOS VENEGAS HURTADO JUAN Qué es 3G? El significado de 3G es tercera generación de transmisión de voz y datos a través

Más detalles

Universidad Técnica Federico Santa María Depto. De Electrónica. Telefonía móvil 3G. Una tecnología que avanza para quedarse atrás.

Universidad Técnica Federico Santa María Depto. De Electrónica. Telefonía móvil 3G. Una tecnología que avanza para quedarse atrás. Universidad Técnica Federico Santa María Depto. De Electrónica Telefonía móvil 3G Una tecnología que avanza para quedarse atrás. Nombre: Diego Rojas Zagals Rol: 2530014 9 Profesor: Agustín González Fecha:

Más detalles

GLOSARIO 1.2G: 2-2.5G 3G: Bluetooth: Bps: Bits por Segundo CEPT (European Postal Telephone and Telegraph):

GLOSARIO 1.2G: 2-2.5G 3G: Bluetooth: Bps: Bits por Segundo CEPT (European Postal Telephone and Telegraph): GLOSARIO 1.2G: Segunda generación de la telefonía móvil. Nace en el momento en el que se empieza a utilizar la tecnología digital para las comunicaciones móviles, a través de una red GSM, en 1991. 2-2.5G:

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

TIPOS DE REDES QUE CONFORMAN INTERNET. LAN, WAN, MAN, WLAN, WMAN, WWMAN, SAN y PAN: Qué significa cada término?

TIPOS DE REDES QUE CONFORMAN INTERNET. LAN, WAN, MAN, WLAN, WMAN, WWMAN, SAN y PAN: Qué significa cada término? TIPOS DE REDES QUE CONFORMAN INTERNET LAN, WAN, MAN, WLAN, WMAN, WWMAN, SAN y PAN: Qué significa cada término? En la actualidad, es casi imposible pensar en un mundo en donde las redes de computadoras

Más detalles

Tecnología IP para videovigilancia... Los últimos avances han hecho posible conectar cámaras directamente a una red de ordenadores basada en el

Tecnología IP para videovigilancia... Los últimos avances han hecho posible conectar cámaras directamente a una red de ordenadores basada en el para videovigilancia....... Los últimos avances han hecho posible conectar cámaras directamente a una red de ordenadores basada en el protocolo IP. La tecnología de las cámaras de red permite al usuario

Más detalles

TRABAJO PRACTICO Nº 3 Procesador de Textos Año 2011. Fibra Optica (El Cable) Conexión Vía Satélite. Teléfonos Móviles. Ondas de Radio.

TRABAJO PRACTICO Nº 3 Procesador de Textos Año 2011. Fibra Optica (El Cable) Conexión Vía Satélite. Teléfonos Móviles. Ondas de Radio. Conexión Telefónica RTC (Red Telefónica Conmutada) TIPOS DE CONEXIONES A INTERNET RDSI (Red digital de servicios Integrados) ADSL (Linea de Abonado Digital Asimetrica) Fibra Optica (El Cable) Conexión

Más detalles

OBLIGACIONES DE HACER INSTITUCIONES PÚBLICAS (INSTITUCIONES EDUCATIVAS, HOSPITALES Y CENTROS DE SALUD) DECRETO 2044 DE 2013

OBLIGACIONES DE HACER INSTITUCIONES PÚBLICAS (INSTITUCIONES EDUCATIVAS, HOSPITALES Y CENTROS DE SALUD) DECRETO 2044 DE 2013 OBLIGACIONES DE HACER INSTITUCIONES PÚBLICAS (INSTITUCIONES EDUCATIVAS, HOSPITALES Y CENTROS DE SALUD) DECRETO 2044 DE 2013 ANEXO 5 MONITOREO Y SISTEMAS DE INFORMACION JUNIO 2014 ÍNDICE DE CONTENIDOS MONITOREO

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción Nombre del Tema Aspectos de seguridad en aplicaciones basadas en WIFI. Asesor: Dr. Oleg Starostenko Basarab Actualidad y Definición del problema Desde hace ya tiempo nos hemos

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes

Más detalles

Capítulo 1: Introducción

Capítulo 1: Introducción Capítulo 1: Introducción El presente trabajo se ubica en el área de administración de redes inalámbricas de computadoras y tiene como objetivo crear una propuesta de solución para permitir un manejo más

Más detalles

Capítulo 8. Conclusiones.

Capítulo 8. Conclusiones. Capítulo 8. Conclusiones. En la actualidad en México estamos viviendo en un estándar de segunda generación de telefonía celular, GSM en su mayoría ocupa la mayoría de las redes existentes a escala mundial,

Más detalles

Capas del Modelo ISO/OSI

Capas del Modelo ISO/OSI Modelo ISO/OSI Fue desarrollado en 1984 por la Organización Internacional de Estándares (ISO), una federación global de organizaciones que representa aproximadamente a 130 países. El núcleo de este estándar

Más detalles

Introducción En los años 60 s y 70 s cuando se comenzaron a utilizar recursos de tecnología de información, no existía la computación personal, sino que en grandes centros de cómputo se realizaban todas

Más detalles

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN Tabla de Contenidos LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN... 1 Tabla de Contenidos... 1 General... 2 Uso de los Lineamientos Estándares...

Más detalles

rutas e información relacionada con puntos de interés en la UDLAP. como los requerimientos de hardware y software establecidos.

rutas e información relacionada con puntos de interés en la UDLAP. como los requerimientos de hardware y software establecidos. Capítulo I. Planteamiento del problema Este capítulo presentará la introducción y planteamiento del problema a resolver por el sistema que se implementará, llamado Navin, un servicio basado en localización

Más detalles

DESARROLLADOR ANDROID INTRODUCCIÓN ANDROID. Ing. Marco Antonio Toscano Freire mtoscano@matoosfe.com tw: martosfre

DESARROLLADOR ANDROID INTRODUCCIÓN ANDROID. Ing. Marco Antonio Toscano Freire mtoscano@matoosfe.com tw: martosfre DESARROLLADOR ANDROID INTRODUCCIÓN ANDROID Ing. Marco Antonio Toscano Freire mtoscano@matoosfe.com tw: martosfre Introducción Aplicaciones Móbiles Desventajas Tanto las pantallas como teclados son demasiado

Más detalles

.TEL Un uso innovador del DNS

.TEL Un uso innovador del DNS .TEL Unusoinnovador deldns 1 de 5 EL CONCEPTO El servicio.tel utiliza el sistema de nombres de dominio (DNS) de forma que permite a los propietarios de dominios.tel controlar cómo y dónde otras personas

Más detalles

WEB APP VS APP NATIVA

WEB APP VS APP NATIVA WEB APP VS APP NATIVA Agosto 2013 Por Jesús Demetrio Velázquez 1 Ya decidió hacer su aplicación en Web App o App Nativa? Debido a que surgieron varias preguntas relacionadas con nuestro artículo Yo Mobile,

Más detalles

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com

Introducción a los Servicios Web. Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Introducción a los Servicios Web Ing. José Luis Bugarin ILUMINATIC SAC jbugarin@consultorjava.com Servicios Web y Soa En un contexto SOA y los servicios web son una oportunidad de negocios en la actualidad.

Más detalles

PLANEAMIENTO DE LAS COMUNICACIONES EN EMERGENCIAS REDES PRIVADAS DISPONIBLES EN EMERGENCIAS TELEFONÍA VÍA SATÉLITE. Índice

PLANEAMIENTO DE LAS COMUNICACIONES EN EMERGENCIAS REDES PRIVADAS DISPONIBLES EN EMERGENCIAS TELEFONÍA VÍA SATÉLITE. Índice Índice 1. REDES PRIVADAS. TELEFONÍA VIA SATÉLITE...2 1.1 SERVICIOS VIA SATELITE... 2 1.1.1 SATELITES GEOESTACIONARIOS... 2 1.1.2 Satelites no Geoestacionarios... 4 1.1.2.1 CARACTERÍSTICAS...4 1.1.2.2 TIPOS.

Más detalles

Redes de Computadores I

Redes de Computadores I Redes de Computadores I Proyecto Dropbox Guillermo Castro 201021015-4 Javier Garcés 201021002-2 4 de septiembre de 2013 3 PROTOCOLOS DB-LSP Y DB-LSP-DISC 1. Resumen La sincronización de archivos es hoy,

Más detalles

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas:

Los mayores cambios se dieron en las décadas de los setenta, atribuidos principalmente a dos causas: SISTEMAS DISTRIBUIDOS DE REDES 1. SISTEMAS DISTRIBUIDOS Introducción y generalidades La computación desde sus inicios ha sufrido muchos cambios, desde los grandes equipos que permitían realizar tareas

Más detalles

4. Programación Paralela

4. Programación Paralela 4. Programación Paralela La necesidad que surge para resolver problemas que requieren tiempo elevado de cómputo origina lo que hoy se conoce como computación paralela. Mediante el uso concurrente de varios

Más detalles

TEMA: PROTOCOLOS TCP/IP

TEMA: PROTOCOLOS TCP/IP TEMA: PROTOCOLOS TCP/IP HISTORIA: El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de

Más detalles

DETERMINACIÓN DE LA DEMANDA Y DEFINICION DE LOS SERVICIOS A BRINDAR. 4.1 Analisis de la demanda de servicios de banda ancha en Lima Metropolitana

DETERMINACIÓN DE LA DEMANDA Y DEFINICION DE LOS SERVICIOS A BRINDAR. 4.1 Analisis de la demanda de servicios de banda ancha en Lima Metropolitana CAPITULO 4 DETERMINACIÓN DE LA DEMANDA Y DEFINICION DE LOS SERVICIOS A BRINDAR. 4.1 Analisis de la demanda de servicios de banda ancha en Lima Metropolitana A medida que han transcurrido los años la demanda

Más detalles

UNIVERSIDAD DE SALAMANCA

UNIVERSIDAD DE SALAMANCA UNIVERSIDAD DE SALAMANCA FACULTAD DE CIENCIAS INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Resumen del trabajo práctico realizado para la superación de la asignatura Proyecto Fin de Carrera. TÍTULO SISTEMA

Más detalles

Introducción a las redes de computadores

Introducción a las redes de computadores Introducción a las redes de computadores Contenido Descripción general 1 Beneficios de las redes 2 Papel de los equipos en una red 3 Tipos de redes 5 Sistemas operativos de red 7 Introducción a las redes

Más detalles

Sistema de marketing de proximidad

Sistema de marketing de proximidad Dizan Vasquez Propuesta de proyecto Sistema de marketing de proximidad ACME México Dizan Vasquez Índice general 1. Descripción 3 2. Resúmen ejecutivo 4 2.1. Objetivo.................................................

Más detalles

Descripción de las tecnologías de telecomunicaciones de ANTEL y sus posibilidades de desarrollo.

Descripción de las tecnologías de telecomunicaciones de ANTEL y sus posibilidades de desarrollo. Descripción de las tecnologías de telecomunicaciones de ANTEL y sus posibilidades de desarrollo. Ing. Fernando Fontán División Técnica de Desarrollo www.antel.com.uy Desarrollo de la comunicaciones inalámbricas

Más detalles

qué supone para el profesional móvil?

qué supone para el profesional móvil? características Conozca la banda ancha WWAN Conozca la banda ancha WWAN: qué supone para el profesional móvil? Cada vez más, una conectividad impecable de alta velocidad es esencial para el éxito de cualquier

Más detalles

La Pirámide de Solución de TriActive TRICENTER

La Pirámide de Solución de TriActive TRICENTER Información sobre el Producto de TriActive: Página 1 Documento Informativo La Administración de Sistemas Hecha Simple La Pirámide de Solución de TriActive TRICENTER Información sobre las Soluciones de

Más detalles

Laboratorio III de Sistemas de Telecomunicaciones Departamento de Telemática

Laboratorio III de Sistemas de Telecomunicaciones Departamento de Telemática Proyecto: Interoperabilidad entre una Red de Telefonía IP y una red de Radio VHF Objetivos Lograr la interoperabilidad de clientes de VoIP con clientes de Radio VHF Implementar el servicio de Call Center

Más detalles

Metodologías de diseño de hardware

Metodologías de diseño de hardware Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción

Más detalles

EVOLUCIÓN A LA TERCERA GENERACIÓN

EVOLUCIÓN A LA TERCERA GENERACIÓN EVOLUCIÓN A LA TERCERA GENERACIÓN MOTOROLA: Alexander Zawadzki Perú Alexander Zawadzki es Gerente de Producto GSM/GPRS para América Latina de Motorola, empresa donde trabaja desde 1996. El es Ingeniero

Más detalles

Seminario Electrónico de Soluciones Tecnológicas sobre Ethernet de Largo Alcance

Seminario Electrónico de Soluciones Tecnológicas sobre Ethernet de Largo Alcance Seminario Electrónico de Soluciones Tecnológicas sobre Ethernet de Largo Alcance 1 de 12 Seminario Electrónico de Soluciones Tecnológicas sobre Ethernet de Largo Alcance 3 Bienvenida. 4 Objetivos. 5 Requerimientos

Más detalles

El grupo de trabajo IEEE 802.15 ha definido tres clases de WPANs que se

El grupo de trabajo IEEE 802.15 ha definido tres clases de WPANs que se 2 Disposiciones generales. 2.1 Tipos de WPANs. El grupo de trabajo IEEE 802.15 ha definido tres clases de WPANs que se diferencian por su rango de datos, consumo de energía y calidad de servicio (QoS).

Más detalles

IP Multimedia Subsystem, un enfoque a redes de siguiente generación en busca de la convergencia tecnológica y los servicios multimedia en Jalisco

IP Multimedia Subsystem, un enfoque a redes de siguiente generación en busca de la convergencia tecnológica y los servicios multimedia en Jalisco IP Multimedia Subsystem, un enfoque a redes de siguiente generación en busca de la convergencia tecnológica y los servicios multimedia en Jalisco Contenido Modalidad de titulación... 2 Motivación... 2

Más detalles

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN Los protocolos de capa de aplicación de TCP/IP más conocidos son aquellos que proporcionan intercambio de la información

Más detalles

Servicios remotos de Xerox Un paso en la dirección correcta

Servicios remotos de Xerox Un paso en la dirección correcta Servicios remotos de Xerox Un paso en la dirección correcta Diagnostica problemas Evalúa datos de la máquina Solución de problemas Seguridad de cliente garantizada 701P42953 Acerca de los Servicios remotos

Más detalles

Seminario Electrónico de Soluciones Tecnológicas sobre Acceso Remoto. 1 de 12

Seminario Electrónico de Soluciones Tecnológicas sobre Acceso Remoto. 1 de 12 Seminario Electrónico de Soluciones Tecnológicas sobre Acceso Remoto 1 de 12 Seminario Electrónico de Soluciones Tecnológicas sobre Acceso Remoto 3 Bienvenida. 4 Objetivos. 5 Aplicaciones para las empresas

Más detalles

Plan de ahorro en costes mediante telefonía IP

Plan de ahorro en costes mediante telefonía IP Plan de ahorro en costes mediante telefonía IP Sección de Telefonía IP IngeniaTIC Desarrollo S.L. PLAN DE AHORRO EN COSTES MEDIANTE TELEFONÍA IP Sección de Telefonía IP Introducción El presente documento

Más detalles

CONTRALORIA GENERAL DE LA REPUBLICA UNIDAD DE TECNOLOGIAS DE INFORMACION POLITICAS DE USO DE LA RED INALAMBRICA INSTITUCIONAL

CONTRALORIA GENERAL DE LA REPUBLICA UNIDAD DE TECNOLOGIAS DE INFORMACION POLITICAS DE USO DE LA RED INALAMBRICA INSTITUCIONAL CONTRALORIA GENERAL DE LA REPUBLICA UNIDAD DE TECNOLOGIAS DE INFORMACION POLITICAS DE USO DE LA RED INALAMBRICA INSTITUCIONAL AÑO 2009 1 POLITICAS DE USO DE LA RED INALAMBRICA INSTITUCIONAL 1. INTRODUCCION.

Más detalles

INTERNET LA RED WAN MAS GRANDE

INTERNET LA RED WAN MAS GRANDE En sus principios, Internet era utilizada exclusivamente para investigaciones científicas, educativas y militares. En 1991, las reglamentaciones cambiaron para permitir que las empresas y los usuarios

Más detalles

OLIMPO Servidor Universal

OLIMPO Servidor Universal OLIMPO Servidor Universal Documento 20050714/01 Fecha Creación Julio 2005 Fecha Última Revisión Agosto 2007 Versión de documento 2.0 1/7 Visión Global Desde el año 1984, en IGT Microelectronics hemos ofrecido

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

ESCUELA NORMAL PROF. CARLOS A CARRILLO

ESCUELA NORMAL PROF. CARLOS A CARRILLO ESCUELA NORMAL PROF. CARLOS A CARRILLO QUE ES UNA RED L A S T I C S E N L A E D U C A C I O N P R E E S C O L A R P R O F. C R U Z J O R G E A R A M B U R O A L U M N A : D U L C E C O R A Z Ó N O C H

Más detalles

INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia

INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia INTRODUCCION. Ing. Camilo Zapata czapata@udea.edu.co Universidad de Antioquia Qué es una Red? Es un grupo de computadores conectados mediante cables o algún otro medio. Para que? compartir recursos. software

Más detalles

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. UNIVERSIDAD DE CARABOBO FACULTAD DE CIENCIA Y TECNOLOGÍA DIRECCION DE EXTENSION COORDINACION DE PASANTIAS Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere. Pasante:

Más detalles

En este capítulo se presenta el marco teórico sobre las redes inalámbricas que utilizan el

En este capítulo se presenta el marco teórico sobre las redes inalámbricas que utilizan el Capítulo 2 Estándar IEEE 802.11 En este capítulo se presenta el marco teórico sobre las redes inalámbricas que utilizan el WEP como protocolo de seguridad. Se mencionan las características generales de

Más detalles

El Modelo de Referencia OSI

El Modelo de Referencia OSI El Modelo de Referencia OSI Tabla de Contenidos 2. El Modelo de Referencia OSI... 2 2.1 Nivel físico...4 2.2 Nivel de enlace... 4 2.3 Nivel de red... 5 2.4 Nivel de transporte...5 2.5 Nivel de sesión...

Más detalles

OBSERVER Que topologías para el Análisis y Monitoreo de Redes contempla?

OBSERVER Que topologías para el Análisis y Monitoreo de Redes contempla? 1 OBSERVER Que topologías para el Análisis y Monitoreo de Redes contempla? LAN Control 10/100/1000 Ethernet; Token Ring; FDDI (Fibra Óptica) Decodifican y analizan más de 450 protocolos en tiempo real.

Más detalles

TELECOMUNICACIONES Y REDES

TELECOMUNICACIONES Y REDES TELECOMUNICACIONES Y REDES Redes Computacionales I Prof. Cristian Ahumada V. Unidad VII: Capa de Enlace de Datos Contenido 1. Introducción. 2. Acceso al Medio. 3. Técnicas de Control de acceso al medio.

Más detalles

COLEGIO COMPUESTUDIO

COLEGIO COMPUESTUDIO COLEGIO COMPUESTUDIO ÁREA: TECNOLOGIA E INFORMATICA DOCENTE: WILLY VIVAS LLOREDA ESTUDIANTE: CLEI: III GUIA N 5 N SESIONES: NUCLEO TEMÁTICO: UNIDAD: 2 Sistema operativo (Windows) OBJETIVO: Comprender el

Más detalles

SERVIDOR WEB PARA ACCESO EN TIEMPO REAL A INFORMACIÓN METEOROLÓGICA DISTRIBUIDA

SERVIDOR WEB PARA ACCESO EN TIEMPO REAL A INFORMACIÓN METEOROLÓGICA DISTRIBUIDA SERVIDOR WEB PARA ACCESO EN TIEMPO REAL A INFORMACIÓN METEOROLÓGICA DISTRIBUIDA E. SÁEZ, M. ORTIZ, F. QUILES, C. MORENO, L. GÓMEZ Área de Arquitectura y Tecnología de Computadores. Departamento de Arquitectura

Más detalles

UNIVERSIDAD TECNICA DEL NORTE

UNIVERSIDAD TECNICA DEL NORTE UNIVERSIDAD TECNICA DEL NORTE FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS Objetivos CARRERA DE INGENIERIA EN ELECTRONICA Y REDES DE COMUNICACIÓN REDES DE NUEVA GENERACION Realizar una gira de visita técnica

Más detalles

Aspectos Básicos de Networking

Aspectos Básicos de Networking Aspectos Básicos de Networking ASPECTOS BÁSICOS DE NETWORKING 1 Sesión No. 4 Nombre: Capa de transporte del modelo OSI Objetivo: Al término de la sesión el participante aplicará las principales características

Más detalles

Soporte Técnico de Software HP

Soporte Técnico de Software HP Soporte Técnico de Software HP Servicios Tecnológicos HP Servicios contractuales Datos técnicos El Soporte Técnico de Software HP ofrece servicios integrales de soporte remoto de para los productos de

Más detalles

Infraestructura Tecnológica. Sesión 2: Mejoras adicionales al servidor de archivos

Infraestructura Tecnológica. Sesión 2: Mejoras adicionales al servidor de archivos Infraestructura Tecnológica Sesión 2: Mejoras adicionales al servidor de archivos Contextualización Los servidores como cualquier equipo de cómputo pueden contar con varias mejoras con las que se pueden

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

UNIVERSIDAD AUTÓNOMA DEL CARIBE

UNIVERSIDAD AUTÓNOMA DEL CARIBE Página: 1/5 UNIVERSIDAD AUTÓNOMA DEL CARIBE SOPORTE DE PLATAFORMA GESTIÓN INFORMÁTICA Página: 2/5 1. OBJETO El objeto del procedimiento es garantizar una plataforma tecnológica y un sistema de comunicación

Más detalles

Fuente: http://www.kzgunea.net

Fuente: http://www.kzgunea.net APRENDE A NAVEGAR SERVICIOS DE INTERNET Internet es como el mercado del pueblo en día de feria. En el mercado los puestos se organizan por secciones: por un lado la fruta, por otro las hortalizas, por

Más detalles

Workflows? Sí, cuántos quiere?

Workflows? Sí, cuántos quiere? Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención

Más detalles

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

CONCEPTOS BÁSICOS. HTML (Hypertext Markup Language) lenguaje de marcas de hipertexto Es el lenguaje en el que están escritas las páginas de la Web.

CONCEPTOS BÁSICOS. HTML (Hypertext Markup Language) lenguaje de marcas de hipertexto Es el lenguaje en el que están escritas las páginas de la Web. INTRODUCCIÓN. Una de las principales características de Internet es que maneja enormes cantidades de información y que en la mayoría de los casos es accesible y gratuita. El reto en todo esto es poder

Más detalles

Windows Server 2012: Infraestructura de Escritorio Virtual

Windows Server 2012: Infraestructura de Escritorio Virtual Windows Server 2012: Infraestructura de Escritorio Virtual Módulo 1: Application Virtualization Módulo del Manual Autores: James Hamilton-Adams, Content Master Publicado: 5 de Octubre 2012 La información

Más detalles

Rede de área local (LAN)

Rede de área local (LAN) Rede de área local (LAN) LAN son las siglas de Local Area Network, Red de área local. Una LAN es una red que conecta los ordenadores en un área relativamente pequeña y predeterminada (como una habitación,

Más detalles

1.- FUNCION DE UNA RED INFORMATICA

1.- FUNCION DE UNA RED INFORMATICA 1.- FUNCION DE UNA RED INFORMATICA Una red de computadoras, también llamada red de ordenadores, red de comunicaciones de datos o red informática, es un conjunto de equipos informáticos y software conectados

Más detalles

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online Guías _SGO Gestione administradores, usuarios y grupos de su empresa Sistema de Gestión Online Índice General 1. Parámetros Generales... 4 1.1 Qué es?... 4 1.2 Consumo por Cuentas... 6 1.3 Días Feriados...

Más detalles

Ahorro de energía visualizando páginas Web en dispositivos móviles heterogéneos

Ahorro de energía visualizando páginas Web en dispositivos móviles heterogéneos ROC&C 06 Ahorro de energía visualizando páginas Web en dispositivos móviles heterogéneos Dr. Juan Gabriel González Serna. M.C. Juan Carlos Olivares Rojas. Acapulco, Guerrero, México, 2006. Agenda Introducción

Más detalles

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... Tabla de Contenido PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO... 2 1. LA PRESENCIA DE INFORMACIÓN Y AYUDA ÚTIL PARA COMPLETAR LOS TRÁMITES EN LÍNEA.... 2 2. LA DISPONIBILIDAD DE DIVERSOS

Más detalles

UNIVERSIDAD TECNICA DEL NORTE

UNIVERSIDAD TECNICA DEL NORTE UNIVERSIDAD TECNICA DEL NORTE FACULTAD DE INGENIERIA EN CIENCIAS APLICADAS ESCUELA DE INGENIERIA EN SISTEMAS COMPUTACIONALES MANUEL DE USUARIO TEMA: SISTEMA INFORMÁTICO PARA LA PROMOCIÓN Y PUBLICIDAD DE

Más detalles

WINDOWS 2008 5: TERMINAL SERVER

WINDOWS 2008 5: TERMINAL SERVER WINDOWS 2008 5: TERMINAL SERVER 1.- INTRODUCCION: Terminal Server proporciona una interfaz de usuario gráfica de Windows a equipos remotos a través de conexiones en una red local o a través de Internet.

Más detalles

CAPÍTULO 1 Instrumentación Virtual

CAPÍTULO 1 Instrumentación Virtual CAPÍTULO 1 Instrumentación Virtual 1.1 Qué es Instrumentación Virtual? En las últimas décadas se han incrementado de manera considerable las aplicaciones que corren a través de redes debido al surgimiento

Más detalles

PROYECTOS DE INVESTIGACIÓN EN LAS AULAS DE CLASE, DE ESTUDIANTES PARA ESTUDIANTES - AQUÍ ESTOY! Y USADIR

PROYECTOS DE INVESTIGACIÓN EN LAS AULAS DE CLASE, DE ESTUDIANTES PARA ESTUDIANTES - AQUÍ ESTOY! Y USADIR PROYECTOS DE INVESTIGACIÓN EN LAS AULAS DE CLASE, DE ESTUDIANTES PARA ESTUDIANTES - AQUÍ ESTOY! Y USADIR ARBELÁEZ B; RENDON L. 1 PROYECTOS DE INVESTIGACIÓN EN LAS AULAS DE CLASE, DE ESTUDIANTES PARA ESTUDIANTES

Más detalles

Infraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor

Infraestructura Tecnológica. Sesión 5: Arquitectura cliente-servidor Infraestructura Tecnológica Sesión 5: Arquitectura cliente-servidor Contextualización Dentro de los sistemas de comunicación que funcionan por medio de Internet podemos contemplar la arquitectura cliente-servidor.

Más detalles

REDES INFORMÁTICAS REDES LOCALES. Tecnología de la Información y la Comunicación

REDES INFORMÁTICAS REDES LOCALES. Tecnología de la Información y la Comunicación REDES INFORMÁTICAS REDES LOCALES INDICE 1. Las redes informáticas 1.1 Clasificación de redes. Red igualitaria. Red cliente-servidor 2. Las redes de área local 2.1 Estructura de una LAN 2.2 Protocolos de

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

unidad redes de computadoras

unidad redes de computadoras unidad 4 redes de computadoras contenidos Compartir recursos Modelo cliente/servidor Tecnologías de la Información y la Comunicación 67 Acerca de esta unidad Una red es un conjunto de computadoras dos

Más detalles

Adelacu Ltda. www.adelacu.com Fono +562-218-4749. Graballo+ Agosto de 2007. Graballo+ - Descripción funcional - 1 -

Adelacu Ltda. www.adelacu.com Fono +562-218-4749. Graballo+ Agosto de 2007. Graballo+ - Descripción funcional - 1 - Graballo+ Agosto de 2007-1 - Índice Índice...2 Introducción...3 Características...4 DESCRIPCIÓN GENERAL...4 COMPONENTES Y CARACTERÍSTICAS DE LA SOLUCIÓN...5 Recepción de requerimientos...5 Atención de

Más detalles

COMERCIO ELECTRÓNICO UNA INTRODUCCIÓN GENERAL

COMERCIO ELECTRÓNICO UNA INTRODUCCIÓN GENERAL This project funded by Leonardo da Vinci has been carried out with the support of the European Community. The content of this project does not necessarily reflect the position of the European Community

Más detalles

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

Más detalles

CAPITULO 2 COMUNICACION ATRAVES DE LA RED

CAPITULO 2 COMUNICACION ATRAVES DE LA RED CAPITULO 2 COMUNICACION ATRAVES DE LA RED INTRODUCCION Las redes nos conectan cada vez más, La tecnología confiable y eficiente permite que las redes estén disponibles cuando y donde las necesitemos. ELEMENTOS

Más detalles

En nuestro capitulo final, daremos las conclusiones y las aplicaciones a futuro

En nuestro capitulo final, daremos las conclusiones y las aplicaciones a futuro Capitulo 6 Conclusiones y Aplicaciones a Futuro. En nuestro capitulo final, daremos las conclusiones y las aplicaciones a futuro para nuestro sistema. Se darán las conclusiones para cada aspecto del sistema,

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

CAPÍTULO I GENERALIDADES

CAPÍTULO I GENERALIDADES CAPÍTULO I GENERALIDADES 1.1. INTRODUCCIÓN Debido al acelerado crecimiento en el desarrollo de las tecnologías de telecomunicación, estas se han convertido en una herramienta imprescindible para tener

Más detalles

ACTIVIDAD No. 2 REPASO DE REDES INFORMATICAS

ACTIVIDAD No. 2 REPASO DE REDES INFORMATICAS ACTIVIDAD No. 2 REPASO DE REDES INFORMATICAS GRADO 11 Nombre(s) y Apellidos: MAYRA CABALLERO Documento: 97071008138 FICHA NÚMERO COLEGIO: Instituto madre del buen consejo FECHA: 23 DE ABRIL 1) Marca la

Más detalles

Sistema de Monitoreo con Sensores Móviles usando Tecnología de Arquitectura Modular. Centro de Modelamiento Matemático Universidad de Chile

Sistema de Monitoreo con Sensores Móviles usando Tecnología de Arquitectura Modular. Centro de Modelamiento Matemático Universidad de Chile Sistema de Monitoreo con Sensores Móviles usando Tecnología de Arquitectura Modular Centro de Modelamiento Matemático Universidad de Chile Julio, 2012 Agenda Introducción Etapa previa: Conceptualización

Más detalles

Ejercicios Tema 1 1.- Supongamos que hay exactamente un switch de paquetes entre un host que envía y un host que recibe. Las tasas de transmisión entre el host que envía y el que recibe son R 1 y R 2 respectivamente.

Más detalles

TRANSFERENCIA DE FICHEROS FTP

TRANSFERENCIA DE FICHEROS FTP TRANSFERENCIA DE FICHEROS FTP INTRODUCCIÓN Internet basa su funcionamiento en un conjunto de protocolos de red sin los cuales la comunicación, a cualquier nivel, sería imposible. Algunos de los protocolos

Más detalles

Dispositivos de Red Hub Switch

Dispositivos de Red Hub Switch Dispositivos de Red Tarjeta de red Para lograr el enlace entre las computadoras y los medios de transmisión (cables de red o medios físicos para redes alámbricas e infrarrojos o radiofrecuencias para redes

Más detalles

Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica)

Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica) Funcionalidades Software SAT GotelGest.Net (Software de Servicio de Asistencia Técnica) Servinet Sistemas y Comunicación S.L. www.softwaregestionsat.com Última Revisión: Octubre 2014 FUNCIONALIDADES SAT

Más detalles

Operación Microsoft Windows

Operación Microsoft Windows Entornos de red Concepto de red En el nivel más elemental, una red consiste en dos equipos conectados entre sí mediante un cable de forma tal que puedan compartir datos. Todas las redes, no importa lo

Más detalles

Información de Producto:

Información de Producto: Windows Server 2008 Foundation La nueva tecnología rentable de Windows Server 2008 Foundation La tecnología confiable y comprobada de Windows Server Foundation proporciona una base para ejecutar las aplicaciones

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

TEMA: Las Redes. NOMBRE Torres Castillo Ana Cristina. PROFESOR: Genaro Israel Casas Pruneda. MATERIA: Las TICS en la educación.

TEMA: Las Redes. NOMBRE Torres Castillo Ana Cristina. PROFESOR: Genaro Israel Casas Pruneda. MATERIA: Las TICS en la educación. TEMA: Las Redes NOMBRE Torres Castillo Ana Cristina. PROFESOR: Genaro Israel Casas Pruneda. MATERIA: Las TICS en la educación. QUÉ ES UNA RED? Una red informática es un conjunto de dispositivos interconectados

Más detalles

Smartphones y Tablets

Smartphones y Tablets Smartphones y Tablets El mundo en tus manos José Enrique García Domingo Ortega Abril 2011 Jornadas TIC para personal técnico del PAS Índice Conceptos Tablets Sistemas Operativos Dispositivos Tendencias

Más detalles

GUÍAS FÁCILES DE LAS TIC

GUÍAS FÁCILES DE LAS TIC GUÍAS FÁCILES DE LAS TIC del COLEGIO OFICIAL DE INGENIEROS DE TELECOMUNICACIÓN Trabajo Premiado 2006 Autor: La Red Internet D. Gerson Aires Casas 17 de Mayo 2006 DIA DE INTERNET GUÍAS FÁCILES DE LAS TIC

Más detalles