TESIS Modelo Accesibilidad Movil a Servicios de...
183
1 MODELO DE ACCESIBILIDAD MÓVIL A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL. PEDRO FRANCISCO CORTES MELO UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES BOGOTÁ, 2015
Transcript of TESIS Modelo Accesibilidad Movil a Servicios de...
1
MODELO DE ACCESIBILIDAD MÓVIL A SERVICIOS DE INFORMACIÓN
GEOGRÁFICA EN LA NUBE COMPUTACIONAL.
PEDRO FRANCISCO CORTES MELO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES BOGOTÁ,
2015
2
MODELO DE ACCESIBILIDAD MÓVIL A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL.
PEDRO FRANCISCO CORTES MELO Código: 20081295006
Tesis de grado presentada como requisito para la obtención del título de Magíster en Ciencias de la Información y las Comunicaciones
DR. JOSÉ NELSON PÉREZ CASTILLO Director
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA
MAESTRÍA EN CIENCIAS DE LA INFORMACIÓN Y LAS COMUNICACIONES BOGOTÁ,
2015
3
Nota de aceptación
_________________________________ _________________________________ _________________________________ _________________________________ _________________________________ _________________________________ _________________________________
_________________________________
Firma del Presidente del Jurado
_________________________________ Firma del Jurado
_________________________________ Firma del Jurado
Bogotá, D.C., Marzo de 2015
4
DEDICATORIA
A mis padres, quienes siempre estuvieron ahí para apoyarme tanto moral
como económicamente.
A mi esposa, a mis hijos, quienes siempre me han brindado su apoyo y comprensión y, supieron entender los momentos que me tuve que alejar de
ellos por terminar con éxito mis estudios de maestría.
A Dios, a la Universidad Distrital Francisco Jose de Caldas, a toda mi familia y, a todos aquellos que me apoyaron directa o indirectamente en esta etapa
de mi vida.
5
Abstract This dissertation started as an initiative of Master of Information and Communication Sciences of the Distrital University Francisco José de Caldas, and comes to be a need to have tools that enable cloud virtual access to GeoInformation to manage and control a network of geospatial information. For this reason, it was decided to design the Model with ESRI technology and NASA Nebula 6. Nebula has tools that should support, enhance and has the potential to distribute, share and to collaborate on geospatial data with large numbers of relevant stakeholders and communities, so they can act upon with purpose and in the easiest manner possible from every single device as a mobile device. A Spatial Data information infrastructure (SDI) provides tools in order to make decision-making processes as the role of geospatial information has changed and is changing rapidly gaining more and more importance in both entities of the Capital District of Bogota and at the level of the companies that interact with spatial information. The dissertation suggests or proposes the development of a conceptual model for building an academic cyber-infrastructure decision support from the academy to the entities of the Capital District of Bogotá, in other words, the model becomes the basis for tool Capital District any entity conducting the decision as to which architectures adopt information technology in order to appropriate policy MinTIC Digital Lives and thereby reduce the gap in terms of existing Information Technology between academic and business reality of our country.
6
TABLA DE CONTENIDO
DEDICATORIA ................................................................................................................................. 4
RESUMEN....................................................................................................................................... 15
INTRODUCCIÓN ........................................................................................................................... 16
1. PLANTEAMIENTO DEL PROBLEMA ................................................................................. 17
1.1. JUSTIFICACIÓN ............................................................................................... 18
1.2 ORGANIZACIÓN DE LA TESIS......................................................................... 19
1.3 OBJETIVOS ...................................................................................................... 20
1.3.1 Objetivo General. ........................................................................................ 20
1.3.2 Objetivos Específicos .................................................................................. 20
1.3.3 Alcance y limitaciones ................................................................................. 20
1.3.4 Pertinencia Social ....................................................................................... 21
1.3.5 Aporte a la Educación ................................................................................. 21
2 MARCO TEÓRICO ................................................................................................................. 22
2.1. SERVICIOS WEB (WEB SERVICES) ................................................................ 22
2.2. ARQUITECTURA ORIENTADA A SERVICIOS - Service-Oriented Architecture (SOA). 23
2.2.1. El paradigma de diseño de la Orientación a Servicios. ................................ 24
2.2.2. Web Services Description Language (WSDL). ............................................ 26
2.2.2.1. Pasos involucrados para proveer y consumir un servicio web ..................... 26
2.2.3. Web Map Service (WMS) ............................................................................ 27
2.2.4. Web Coverage Service (WCS). ................................................................... 29
2.2.5. Web Feature Service (WFS). ...................................................................... 29
2.3. TELEFONÍA MÓVIL........................................................................................... 30
2.3.1. El Concepto de S.I.G. Móvil (Mobile GIS). ................................................... 30
2.3.2. Modelo de Datos Espacial S.I.G. Móvil. ....................................................... 31
2.3.3. Arquitectura Distribuida de Cuatro (4) Capas para S.I.G. Móvil ................... 32
2.4. NUBE COMPUTACIONAL (CLOUD COMPUTING) .......................................... 34
2.4.1. Cloud Computing Framework (Nube Computacional) .................................. 35
2.4.2. Características de la Cloud Computing (Nube Computacional). .................. 37
2.4.3. Retos de la Cloud Computing (Nube Computacional). ................................ 37
7
2.4.4. Modelos básicos de servicio en la nube: ..................................................... 39
2.4.5. Medición del Servicio (Service Measurement Index - SMI). ......................... 40
2.4.6. Arquitectura SMICloud (Service Measurement Index - SMI). ....................... 41
2.4.6.1. SMICloud Broker ......................................................................................... 43
2.4.6.2. Monitoring: .................................................................................................. 43
2.4.6.3. Service Catalogue: ...................................................................................... 43
2.4.7. Clasificación del Servicio Cloud. .................................................................. 44
2.5. APLICACIÓN SOA A LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA. ..... 46
2.5.1. Servicio Cloud Computing para las Ciencias Geoespaciales: ...................... 50
2.6.1.1. Infrastructure as a Service (IaaS) ........................................................................ 50
2.6.1.2. Platform as a Service (PaaS) .............................................................................. 51
2.6.1.3. Software as a Service (SaaS) ............................................................................. 51
2.6.1.4. Data as a Service (DaaS) ................................................................................... 51
2.6. CLOUD COMPUTING ESPACIAL - SPATIAL CLOUD COMPUTING (SCC) ..... 52
2.7. NIMBUS, CLOUD COMPUTING PARA LA CIENCIA. ....................................... 55
2.7.1. Arquitectura NIMBUS Cloud Computing. ..................................................... 56
2.8. NASA-NEBULA CLOUD COMPUTING. ............................................................ 57
2.8.1. Arquitectura NEBULA Cloud Computing. .................................................... 58
2.9. NUBE COMPUTACIONAL MÓVIL (MOBILE CLOUD COMPUTING) ................ 59
2.9.1. Estado del Arte nube computacional móvil (Mobile Cloud Computing). ....... 60
2.9.2. Nube Computacional Vs Nube Computacional Móvil: .................................. 61
2.10. DEFINICIÓN NUBE COMPUTACIONAL MÓVIL (MOBILE CLOUD COMPUTING). ................................................................................................................ 61
2.11. TAXONOMIA DE LA NUBE COMPUTACIONAL MOVIL. .................................. 65
3. DATOS, METODOS E INSTRUMENTOS .......................................................................... 66
3.1. INTRODUCCION ............................................................................................... 66
3.2. RESUMEN EJECUTIVO .................................................................................... 67
3.3. ESTÁNDARES PARA EL NODO IDE DE LA UNIVERSIDAD DISTRITAL ......... 68
3.3.1. Lineamientos para la Política de Información Geográfica de la Universidad Distrital 68
3.4. DEFINICIÓN DE DATOS FUNDAMENTALES DE LA UNIVERSIDAD DISTRITAL 69
3.4.1. Especificación Técnica del Dato Fundamental “Cobertura Educativa” ......... 69
8
3.5. GEOSERVICIOS ............................................................................................... 70
3.5.1 Plataforma Tecnológica para los Geoservicios CECAD de la Universidad Distrital. 70
3.5.1.1. Tecnología propuesta de geoservicios. (arcgis for inspire- esri® geoportal server). 71
3.5.2 Arquitectura del Componente de Servicios Web Geográficos ..................... 75
3.5.2.1. Características Del Core De Los Geoservicios ESRI. .................................. 77
3.5.2.2. Estándares OGC Suportados Por Los Geoservicios ESRI. ......................... 78
3.5.3 Descripción del Servicio Web Geográfico. ................................................... 79
3.5.4 El CECAD, como nodo ofrecera los siguientes formatos de GeoServicios. . 80
3.6. GEOPORTALES ............................................................................................... 82
3.6.1. Plataforma Tecnológica para el Geoportal y el Visor de Información Geográfica 83
3.7. NODOS ............................................................................................................. 86
3.7.1. Plataforma tecnológica para la Gestión de Metadatos ................................. 87
3.7.2. Lineamientos para la creación del nodo de la Universidad Distrital ............. 89
4. MODELO PROPUESTO ....................................................................................................... 90
4.1. INTRODUCCION ............................................................................................... 90
4.1.1. Trabajo Relacionado ................................................................................... 92
a. Métodos centralizados, ................................................................................................ 92
b. Métodos distribuidos .................................................................................................... 93
4.1.2. Principios .................................................................................................... 94
4.1.3.1 Seguridad y Acceso a los Datos .......................................................................... 96
4.1.3.1.1 Integridad: ......................................................................................... 96
4.1.3.1.2 Autenticación: .................................................................................... 96
4.1.3.1.3 Confidencialidad: ............................................................................... 96
4.1.3.2 Gestión de los Recursos Cloud ............................................................................ 96
4.1.3.3 Mobile Client Cloud Computing (MCCC) .............................................................. 97
4.1.3.4 Mobile Server Cloud Computing (MSCC) ............................................................. 97
4.1.3.5 Modelo Cloud ....................................................................................................... 97
4.1.3.6 Servicios RESTful (REpresentational State Transfer) .......................................... 97
4.2. JUSTIFICACIÓN DEL MODELO ....................................................................... 98
4.3. RETOS ACTUALES .......................................................................................... 99
9
4.4. RECURSOS ...................................................................................................... 99
4.5. HERRAMIENTAS, MATERIALES Y MÉTODOS .............................................. 100
4.5.1.Weblets ................................................................................................................. 100
4.5.2. CloneCloud: ......................................................................................................... 102
4.5.3. Cloudlets Basados en VM .................................................................................... 103
4.5.4. Estándares del Open GeoSPatial Consortium (OGC): ......................................... 106
4.5.5. Herramientas Adicionales de Software: ............................................................... 107
4.6. CAPA INTERMEDIA ........................................................................................ 108
4.7. PROS Y CONTRAS......................................................................................... 109
4.8. CASO DE USO ................................................................................................ 109
4.9. DISEÑO DEL MODELO .................................................................................. 111
4.9.1. Solución .................................................................................................... 112
4.9.2. Metodología .............................................................................................. 115
4.9.2.1. Descripción del Modelo ..................................................................................... 115
4.9.2.1 Capa (Layer) 1 ................................................................................................... 118
4.9.2.2 Capa (Layer) 2 ................................................................................................... 119
4.9.2.3 Capa (Layer) 3 ................................................................................................... 120
4.9.2.4 Capa (Layer) 4 ................................................................................................... 122
4.9.2.5 Capa (Layer) 5 ................................................................................................... 124
4.9.2.6 Capa (Layer) 6 ................................................................................................... 127
4.9.2.7 Capa (Layer) 7 ................................................................................................... 127
4.9.3. Arquitectura ............................................................................................... 128
4.9.4. Algoritmos ................................................................................................. 129
4.9.5. Algoritmo Propuesto .................................................................................. 137
4.9.6. Consistencia.............................................................................................. 139
4.9.7. Discusión .................................................................................................. 139
4.9.8. Escalabilidad ............................................................................................. 141
4.9.9. Trabajo Futuro ........................................................................................... 141
4.9.10. Relación entre el Nodo de la Universidad Distrital F.J.C. y el Modelo Computacional Propuesto .............................................................................................. 142
5 CONCLUSIONES Y RECOMENDACIONES ................................................................... 146
10
5.1 RECOMENDACIONES Y LINEAMIENTOS PARA EL DESARROLLO FUTURO DEL MODELO DE ACCESIBILIDAD A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL (NODO) IDE. ............................................................ 146
5.2 CONCLUSIONES ............................................................................................ 147
BIBLIOGRAFÍA ............................................................................................................................. 149
ANEXO A ...................................................................................................................................... 158
SERVICIOS WEB GEOGRAFICOS IMPLEMENTADOS. .............................................. 158
A.1 RECURSOS GEOESPACIALES (GEORECURSOS) .............................................. 161
A.2. ESPECIFICACIÓN DE LA IMPLEMENTACIÓN ..................................................... 162
A.2.1 Web Map Service (WMS) ..................................................................................... 163
A.2.1.1. Que es un Web Map Service (WMS) ................................................................ 163
A.2.1.2. Cómo Funciona el Web Map Service (WMS) .................................................... 164
A.2.2. Web Feature Service (WFS) ................................................................................ 166
A.2.2.1. Que es un Web Feature Service (WFS)............................................................ 166
A.2.2.2. Cómo Funciona el Web Feature Service (WFS) ............................................... 167
A.2.3. Web Processing Service (WPS) .......................................................................... 168
A.2.3.1. Cómo Funciona el Web Processing Service (WPS) .......................................... 168
A.2.4. Geography Markup Language (GML) .................................................................. 174
ANEXO B ...................................................................................................................................... 176
APLICACIÓN REAL SERVICIOS WEB GEOGRAFICOS IMPLEMENTADOS ............... 176
ANEXO C ...................................................................................................................................... 183
CONVENIO MARCO DE COOPERACION ENTRE LA EMPRESA DE ACUEDUCTO ALCANTARILLADO Y ASEO DE BOGOTÁ E.A.B. – E.S.P. Y LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS ............................................................... 183
11
TABLA DE FIGURAS
Figura 1. Funcionamiento de los Servicios Web. ..............................................................................23
Figura 2. Principios de Orientación a Servicios, contribuyen a las metas estratégicas y beneficios
asociados con la computación orientada a servicios. ........................................................................25
Figura 3. Using the Web Services Description Language (WSDL) ...................................................27
Figura 4. Web Map Service................................................................................................................29
Figura 5. Arquitectura Aplicaciones Móviles para Clientes Livianos Internet ....................................30
Figura 6. Arquitectura S.I.G Móvil. .....................................................................................................31
Figura 7. Detalle Sistema OTA. .........................................................................................................32
Figura 8. Arquitectura Distribuida en 4 Capas para SIG Móvil. .........................................................33
Figura 9. Diagrama lógico del SIG Móvil. ..........................................................................................33
Figura 10. Arquitectura Cloud Computing. .........................................................................................34
Figura 11. Framework Cloud Computing. ..........................................................................................36
Figura 12. SMICloud Framework. ......................................................................................................42
Figura 13. Analytical Hierarchical Process (AHP)..............................................................................44
Figura 14. Sistema sencillo basado en servicios. ..............................................................................46
Figura 15. Solución Sistema de Sistemas .........................................................................................48
Figura 16. Framework Spatial Cloud Computing ...............................................................................53
Figura 17. Vista general configuración Cloud ....................................................................................55
Figura 18. Arquitectura NEBULA Cloud Computing ..........................................................................57
Figura 19. Características NEBULA Cloud Computing .....................................................................58
Figura 20. Cloud Computing bajo tecnología Internet Móvil ..............................................................59
Figura 21. Servidor Remoto Cloud abasteciendo Dispositivos móviles a través de internet ............62
Figura 22. Recurso Virtual Cloud configurado con dispositivos móviles vecinos .............................63
12
Figura 23. Dispositivo móvil habilitado Cloudlet para omitir la latencia y problemas de banda ancha
y beneficiarse de estos recursos .......................................................................................................63
Figura 24. Cloudlets Estáticos provisionado por una corporación o un Cloudlet Ad hoc provisto por
una red casera ...................................................................................................................................64
Figura 25. Una Taxonomía de los ítems Mobile Cloud Computing ...................................................65
Figura 26. Arquitectura ArcGIS for INSPIRE .....................................................................................72
Figura 27. Arquitectura ArcGIS Geoportal Server .............................................................................74
Figura 28. Arquitectura ArcGIS Geoservicios Server ........................................................................75
Figura 29. Funcionamiento Servicios web .........................................................................................80
Figura 30. Concepto de Geoportal .....................................................................................................83
Figura 31. Adaptación portal de www.arcgis.com (ArcGIS Online) ...................................................84
Figura 32. Componentes del nodo IDE Universidad Distrital ............................................................86
Figura 33. Catálogo de Metadatos – Geoportal Server .....................................................................87
Figura 34. Arquitectura en tres capas: Dispositivo Móvil, Cloudlet y Núcleo Central (Cloud) ...........90
Figura 35. Vista general Mobile Cloud Computing .........................................................................94
Figura 36. Arquitectura general Mobile Cloud Computing. ................................................................95
Figura 37. Arquitectura MAUI...........................................................................................................101
Figura 38. Flujo de control cliente sustituto. ....................................................................................102
Figura 39. Arquitectura Sistema CloneCloud...................................................................................103
Figura 40. Síntesis Dinámica de VM. ...............................................................................................104
Figura 41. Ciclo de vida Agente Móvil .............................................................................................106
Figura 42. Marco de referencia estándares servicios web para Geoprocesamiento ......................107
Figura 43. Caso de Uso ...................................................................................................................110
Figura 44. Modelo de Accesibilidad móvil a Servicios de Información Geográfica en la Nube
Computacional. ................................................................................................................................111
Figura 45. Ejemplo del algoritmo CDS. ............................................................................................114
13
Figura 46. Diseño Conceptual del Modelo propuesto ......................................................................117
Figura 47. Siguiente Generación de Redes (Next Generation Network-NGN) ...............................119
Figura 48. Área Administrativa Cloudlet .........................................................................................125
Figura 49. Franjas Áreas Administrativas ........................................................................................126
Figura 50. Arquitectura del Modelo propuesto .................................................................................128
Figura 51. Algoritmo propuesto ........................................................................................................137
Figura 52. Integracion MANET (Mobile Ad Hoc Network) ...............................................................144
Figura 53. OGC Web Services (OWS) ............................................................................................159
Figura 54. Catálogos en la librería mundial .....................................................................................160
Figura 55. Recursos Geoespaciales ................................................................................................161
Figura 56. Funcionamiento del WMS ...............................................................................................164
Figura 57. Solicitudes GetCapabilities y GetMap ............................................................................165
Figura 58. Funcionamiento del WFS ...............................................................................................167
Figura 59. Diagrama de actividad cuando el cliente solicita almacenar resultados ........................169
Figura 60. Diagrama de paquetes para la interface WPS ...............................................................170
Figura 61. Diagrama de clases paquete del servicio WPS ..............................................................171
Figura 62. Diagrama de clases paquete GetCapabilities WPS .......................................................172
Figura 63. Diagrama de clases paquete descriptor del proceso .....................................................173
Figura 64. Resultado en entorno real, petición GetMap de un WMS ..............................................174
Figura 65. Diferencia en los resultados de la petición GetMap (WMS) y GetFeature (WFS) .......175
Figura 66. Directorio REST de servicios geográficos Servidor geográfico GIS1 ............................176
Figura 67. Directorio REST de servicios geográficos Servidor geográfico GIS2 ............................176
Figura 68. Ejemplo descripcion de los servicios web geográficos empleados ................................177
14
LISTADO DE TABLAS
Tabla 1. Tipos de GeoServicios ESRI Portal ......................................................... 78
Tabla 2. Porque las Cloudlets son más apropiadas. ..................................... …..105
Tabla 3. Parámetros de Simulación………………………………………………….136
15
RESUMEN
El presente proyecto de investigación aplicará los modelos planteados por organismos internacionales como el OGC (Open Geospatial Consortium) en cuanto a Arquitecturas orientadas a servicios (SOA) para Sistemas de Información Geográfico con el fin de crear un MODELO DE ACCESIBILIDAD MOVIL A SERVICIOS DE INFORMACION GEOGRAFICA EN LA NUBE COMPUTACIONAL. Para llevar a cabo la investigación, se estudiaron temáticas relacionadas y a su vez, se estudiaron los estándares internacionales propuestos por el OGC para Servicios Web GeoEspaciales Móviles en la Nube Computacional (GIS Mobile Cloud Computing). Con base en la investigación, se presentará o se desarrollará un caso de estudio el cual constituye un prototipo computacional experimental, representado por medio de un modelo de servicios aplicado a Sistemas de Información Geográfico (S.I.G.) con tecnología móvil en la nube computacional. Con la culminación del modelo teórico por medio del prototipo computacional experimental, se espera evidenciar si el modelo es válido o no lo es. Si el modelo es válido, aprovecharse como una base para implementaciones futuras de servicios web geográficos con tecnología móvil en la nube computacional en Colombia. Si el modelo es válido, poder concluir que el principal aporte del desarrollo del proyecto, es la adaptación del modelo propuesto por el Open Geospatial Consortium para su funcionamiento en un ambiente de Servicios Web Móvil GeoEspacial en la nube computacional (GIS Mobile Cloud Computing); en el caso que el modelo no sea válido, plantear las recomendaciones pertinentes para trabajos futuros.
16
INTRODUCCIÓN
Muchas de las entidades gubernamentales acá en Colombia, presentan o sirven, por medio de servicios web, información geográfica de diversas fuentes, en diversos formatos y en diversas temáticas. Por ejemplo, el DANE se encarga de publicar o servir información acerca de las estadísticas de calidad de vida, estadísticas demográficas y además, tienen información geográfica básica relacionada con estas temáticas como Departamentos, Municipios, Ciudades, entre otras. De igual manera, por ejemplo, el IDEAM, tiene una temática particular especializada y espacializada como lo es el pronóstico del clima y con base en esta temática publica información relevante o pertinente para llevar a cabo pronósticos meteorológicos; sin embargo, esta entidad también sirve o publica información geográfica base como Departamentos, Municipios, Ciudades, etc., de manera que en ese sentido converge con otras entidades gubernamentales que publican información geográfica. Con el presente proyecto, se busca publicar, consumir y detectar todos aquellos servicios web geográficos que aparecerán en los próximos años en todas estas entidades gubernamentales y privadas, con el fin de intercambiar y descubrir todos aquellos servicios de Geoprocesamiento que se utilizan o emplean con la información geográfica propia de cada temática o negocio desde un dispositivo móvil en la nube computacional.
En los primeros capítulos del presente anteproyecto, se hará una breve descripción de las temáticas involucradas (Web Services, GIS Mobile, Service-
oriented Architecture (SOA), Cloud Computing, ArcGIS Server, es decir, se hará una revisión del estado del arte), las cuales serán el marco de referencia para el planteamiento del modelo y sustentarán teóricamente el desarrollo del proyecto. Con base en el marco teórico, se propondrá el modelo teórico, el cual será una adaptación del modelo propuesto por el Open Geospatial Consortium (OGC), a través de GIS Cloud Computing, y en particular, a través de los Servicios Web GeoEspaciales en la nube computacional (GIS Mobile Cloud Computing), con este capítulo se da cumplimiento al objetivo de integrar en un modelo las recomendaciones del Open Geospatial Consortium (OGC), teniendo en cuenta las características de GIS Cloud Computing, para el tratamiento de información geográfica en la nube computacional con dispositivos móviles.
17
1. PLANTEAMIENTO DEL PROBLEMA
El gobierno nacional en su Plan Nacional de Tecnologías de la Información y las Comunicaciones (TIC), tiene como objetivo que en el año 2019 todos los colombianos estén conectados e informados haciendo uso eficiente de las TIC para una mayor inclusión social y competitividad. [1] Sin embargo, las TIC necesitan de ciertos medios para su difusión tanto en áreas urbanas como en las áreas rurales. En Colombia, existe un inconveniente en cuanto a la difusión de las TIC, en comparación con las áreas rurales, las áreas urbanas ofrecen una rentabilidad mucho mayor y por ende se genera un retorno de inversión mucho mayor, lo cual genera una brecha digital entre las áreas urbanas y rurales. En yuxtaposición, debido al bajo ingreso per-cápita de nuestro país, no todos los hogares tendrán un computador personal o de escritorio; no obstante, las estadísticas de telefonía celular en nuestro país han demostrado que existe prácticamente una línea celular por cada habitante en Colombia y que de todas estas líneas telefónicas, el 15% del mercado posee plan de datos y acceso a internet. En la actualidad, observamos el constante y acelerado cambio tecnológico, este cambio tiende a eliminar las fronteras entre dispositivos y tecnología y entre áreas rurales y áreas urbanas para el intercambio de información. Tanto así que "...Posiblemente sea en estas áreas rurales donde las TIC pueden desplegar todo su potencial de desarrollo. El simple acceso a un teléfono, situado en una cabina pública, en una tienda del pueblo o en un centro comunitario, podría mejorar la atención de salud y la seguridad en la comunidad, e incluso salvar vidas en situaciones de emergencia." (Saravia, 2003) La brecha que ha separado tradicionalmente a ricos y pobres es pequeña comparada con la brecha que separa a usuarios conectados y usuarios desconectados de internet. El presente proyecto de investigación, analizará y desarrollará un modelo de accesibilidad móvil con el fin de apropiar las TIC tanto en áreas rurales y urbanas, como mecanismo para disminuir la exclusión digital en Colombia. En este orden de ideas, surge la pregunta de investigación o hipótesis: Es posible incrementar la accesibilidad a Internet Móvil, mediante el ofrecimiento de servicios web geográficos en la nube computacional de fácil acceso, que resulten de gran utilidad y sean muy atractivos para los usuarios, a un bajo costo (desde la academia) contribuyendo de esta forma, en la meta del gobierno nacional para lograr que las TIC potencien y reten la capacidad de investigar, desarrollar, innovar y emprender nuevos modelos tecnológicos aplicados a muestras necesidades y a nuestro entorno colombiano.
18
1.1. JUSTIFICACIÓN
La Universidad Distrital Francisco José de Caldas tiene dentro de sus planes ofrecer el Doctorado de Ingeniería; para ello ha dispuesto un laboratorio el cual cuenta con un centro de cómputo habilitado para la implementación de Cloud Computing. Este proyecto de investigación pretende encontrar una nueva propuesta e innovar en el campo de investigación apoyado en el laboratorio del CENTRO DE COMPUTACION DE ALTO DESEMPEÑO -CECAD- ofreciendo de esta manera Servicios Web GeoEspaciales Móviles en la Nube Computacional (Cloud Computing). Basado en la experiencia con los Sistemas de Información Geográfica (S.I.G.), los S.I.G. han sido acompañados durante su existencia por la tecnología informática y específicamente por servicios web habilitados para soportar información GeoEspacial (Geospatial Web Services), tecnología Móvil, información proveniente de diferentes fuentes y por supuesto, es imprescindible que los S.I.G. operen en GIS Mobile Cloud Comptuing. Sin embargo y a pesar que los S.I.G. han sido empleados tradicionalmente para la producción y publicación cartográfica, para el análisis de riesgos, para la toma de decisiones relacionada con información espacial, para análisis de usos del suelo, los S.I.G. pueden aplicarse a muchas otros dominios de la ciencia y en este caso el número y el tipo de aplicaciones se expande considerablemente. Este proyecto de investigación propondrá un prototipo computacional experimental, para lo cual se implementará un modelo de servicios S.I.G. móvil en la nube computacional, esto con el fin de atender la demanda de usuarios que no cuentan con el tiempo suficiente para actividades cotidianas como conocer la ubicación de sitios de interés como hoteles, parqueaderos, restaurantes, etc, de la ciudad donde se encuentra ni tampoco cuentan con un dispositivo Móvil con GPS en su celular para ubicar dichos sitios de interés, este proyecto proporcionará el servicio a través de GIS Mobile Cloud Computing empleando para ello únicamente comunicación Móvil sin necesidad de tecnología GPS en el dispositivo Móvil. Para el desarrollo del presente proyecto de investigación se implementará un prototipo computacional experimental, el cual servirá de apoyo con el fin de corroborar la hipótesis plantead; el prototipo se soportara en el laboratorio del CENTRO DE COMPUTACION DE ALTO DESEMPEÑO -CECAD- de la Universidad Distrital F.J.C., lo cual servirá de punto de partida para la creación de un ambiente de nube computacional S.I.G. (GIS Cloud Computing) para el CECAD.
19
El impacto social de este proyecto se podrá medir por medio del prototipo experimental, el cual fortalecerá el área cognitiva de los profesionales que están involucrados con el manejo de información Geoespacial, servicios web geográficos y GIS Mobile Cloud Computing; para el caso en particular, se potenciara el aprendizaje y aplicación de las TIC’s en nuestro entorno con un compromiso cognitivo avanzado. Con el proyecto “MODELO DE ACCESIBILIDAD MOVIL A SERVICIOS DE INFORMACION GEOGRAFICA EN LA NUBE COMPUTACIONAL”, se propondrá una forma de mover el almacenamiento y el procesamiento de los datos geográficos desde los dispositivos móviles hacia la nube computacional y en particular, hacia el ambiente de nube computacional del CECAD. Este prototipo computacional experimental permitirá innovar en el ámbito nacional y aportar el medio por el cual se satisfaga la demanda de servicios geográficos móviles en la nube computacional en nuestro país y por ende, proveer un medio que garantice la accesibilidad de los usuarios a las Tecnologías de la Información logrando hacer un aporte investigativo a nuestra sociedad Colombiana.
1.2 ORGANIZACIÓN DE LA TESIS
El trabajo de investigación, se organizó de la siguiente forma: Capítulo 1 planteamiento del problema y los objetivos propuestos. Capítulo 2 presenta el marco teórico sobre el cual se apoyó el trabajo de investigación. Capítulo 3 describe los datos, métodos e instrumentos. Capítulo 4 Describe el modelo computacional experimental y empírico propuesto para el presente trabajo de investigación, así mismo, señala el trabajo futuro en la línea de investigación (Mobile Cloud Computing - MCC). Capítulo 5 presenta las conclusiones y recomendaciones basadas en el modelo propuesto en el presente trabajo de investigación.
20
1.3 OBJETIVOS
1.3.1 Objetivo General.
Desarrollar un MODELO DE ACCESIBILIDAD MÓVIL A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL sobre un entorno virtual computacional con el fin de publicar servicios Geográficos y exponer aplicaciones S.I.G. ejecutándose como servicios web sobre una plataforma GIS Mobile Cloud Computing, para satisfacer la creciente demanda de soluciones de software consumibles únicamente por medio de comunicación Móvil.
1.3.2 Objetivos Específicos
• Reunir en un solo modelo conceptual las recomendaciones existentes que propone el Open Geospatial Consortium (OGC) para servicios web de notificación y registro de información geográfica.
• Analizar y proponer alternativas de despliegue de aplicaciones web Móvil con componente GeoEspacial en GIS Mobile Cloud Computing, con el fin de satisfacer la creciente demanda por soluciones TIC en el sector productivo colombiano, en particular, la demanda de servicios web geográficos con tecnología móvil en la nube computacional contribuyendo en la consolidación del plan TIC del gobierno nacional.
• Establecer los componentes básicos que definen el Modelo de Accesibilidad Móvil a Servicios de Información Geográfica en la Nube Computacional del proyecto de investigación.
• Conocer las mejores condiciones para la apropiación de las Tecnologías de la Información y la Comunicación (TIC) en Colombia.
• Juzgar la validez de los resultados obtenidos en la investigación propuesta en la tesis de Maestría, a través del análisis, diseño e implementación de las herramientas informáticas que soporten la publicación de aplicaciones geográficas web móviles como servicios en GIS Mobile Cloud Computing - Software as a Service (SaaS).
1.3.3 Alcance y limitaciones
La presente investigación tiene como alcance diseñar e implementar un modelo de accesibilidad móvil con el fin de exponer servicios web geográficos en dispositivos
21
móviles, a través de un ambiente GIS Mobile Cloud Computing, por medio del cual se definirá un modelo teórico, tomando como base las recomendaciones planteadas por el Open Geospatial Consortium (OGC) para Servicios Web GeoEspaciales, servicios Rest, formatos REST/JSON, especificaciones o estándares para servicios web como WMS (Web Map Service), WFS (Web Feature Service), y WCS (Web Coverage Service), entre otros; esto se trasladará a un caso de estudio, que validará el proyecto. La limitación del presente proyecto es, lograr una Infraestructura GIS Mobile Cloud Computing y exponer aplicaciones S.I.G. ejecutándose como servicios web GeoEspaciales en la Infraestructura Cloud Computing del laboratorio que la Universidad Distrital F.J.C. ha dispuesto para el doctorado en ingeniería (CECAD). Adicionalmente, el modelo teórico se podrá emplear como una base para cualquier otro sistema que requiera manipular información geográfica en un ambiente computacional Cloud y específicamente en un ambiente de Servicios Web GeoEspaciales en la nube computacional (GIS Mobile Cloud Computing).
1.3.4 Pertinencia Social
El presente proyecto impacta en la comunidad académica puesto que fortalecerá el área cognitiva de los profesionales comprometidos con el manejo de los datos geográficos en un ambiente de Servicios Web GeoEspaciales en la nube computacional (GIS Mobile Cloud Computing), el impacto social será a nivel local, regional y nacional. De igual manera, se generará un impacto en la comunidad científica dedicada al estudio de los fenómenos GeoEspaciales, ya que servirá como soporte para el intercambio de información geográfica en la nube computacional con tecnología móvil.
1.3.5 Aporte a la Educación
Desde el punto de vista académico, el presente proyecto impactará en la educación puesto que sirve de base para la creación de una plataforma Cloud Computing, la cual permitirá compartir recursos e información en la comunidad académica y científica. En el contexto del aula universitaria, apoyará a la comunidad académica que orienta sus estudios en los Servicios Web GeoEspaciales Móviles en la nube computacional (GIS Mobile Cloud Computing).
22
2 MARCO TEÓRICO
Los Sistemas de Información Geográfica (S.I.G.) integran información propia de un negocio determinado, por ejemplo, por medio de los S.I.G. se puede determinar cuál es la ubicación más cercana con relación a la dirección o ubicación de un usuario y, evaluar la ubicación de todas las tiendas más cercanas a dicho usuario, es decir, llevar a cabo un análisis de demanda. Adicional a ello, los Sistemas de Información Geográfica poseen u ofrecen la capacidad de dejar ver patrones de comportamiento en los datos, tanto en datos 2D como en información tridimensional (3D), con el fin de llevar a cabo complejos análisis espaciales para resolver todo tipo de preguntas GeoEspaciales. Los S.I.G. se han ido envolviendo muy rápidamente desde su único y tradicional rol en el departamento o área de cartografía hasta llegar al sitio que se encuentra hoy en día, es decir, han adoptado un rol mucho más visible y establecido a nivel corporativo o empresarial.
2.1. SERVICIOS WEB (WEB SERVICES)
Existen múltiples definiciones acerca de los Servicios Web, sin embargo y de acuerdo con el World Wide Web Consortium (W3C: comunidad internacional que desarrolla estándares que aseguran el crecimiento de la Web a largo plazo), los Servicios Web se definen de la siguiente manera: Los Servicios Web (Web Services), son “un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web”. (Ver Figura 1).
23
De acuerdo con el World Wide Web Consortium (W3C) los Servicios Web sirven o son usados por que “proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones web, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones web, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.” [33]
Figura 1. Funcionamiento de los Servicios Web.
Fuente: http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb
2.2. ARQUITECTURA ORIENTADA A SERVICIOS - Service-Oriented Architecture (SOA).
De acuerdo con Service-Oriented Computing Series de Thomas Erl, “En el mundo de SOA y de la orientación a servicios, el término "servicio" no es genérico. Tiene connotaciones específicas que se refieren a una combinación única de características de diseño. Cuando la lógica resolutiva es consistentemente construida como servicio y cuando los servicios son también consistentemente diseñados con estas características comunes, la orientación a servicios se logra exitosamente a través de su entorno”.[34]
24
Una Arquitectura Orientada a Servicios - Service-Oriented Architecture (SOA), es una colección de servicios, en donde estos servicios se comunican los unos con los otros en un ambiente web. Esta comunicación puede incluir desde el simple paso de mensajes hasta, el paso de dos o más servicios de manera simultánea y coordinada con el fin de resolver alguna tarea o solicitud específica.
2.2.1. El paradigma de diseño de la Orientación a Servicios.
Existen diferentes paradigmas de diseño para la lógica resolutiva distribuida. Lo que distingue la orientación a servicios es la manera en la cual lleva a cabo la separación de intereses y cómo conforma las unidades individuales de lógica resolutiva. [34] El aplicar la orientación a servicios en un grado significativo tiene como resultado que la lógica resolutiva puede clasificarse - con cierta seguridad - como "orientada a servicios", y las unidades como "servicios" (Ver Figura 2). Para comprender exactamente lo que esto significa, se requiere apreciar las metas estratégicas de la orientación a servicios combinado con el conocimiento de los principios de diseño orientados a servicios descritos a continuación:[34] • Estandarización de los Contratos de Servicios. • El Bajo Acoplamiento de los Servicios. • La Abstracción de los Servicios. • La Reutilizabilidad de los Servicios. • La Autonomía de los Servicios. • La Carencia de Estados de los Servicios. • La Descubribilidad de los Servicios. • La Compuestabilidad de los Servicios.
25
Figura 2. Principios de Orientación a Servicios, contribuyen a las metas estratégicas y beneficios asociados con la computación orientada a servicios.
Fuente: http://soaprinciples.com
26
2.2.2. Web Services Description Language (WSDL).
WSDL es un formato XML para describir servicios en la red como un conjunto de puntos finales (endpoints) que operan sobre los mensajes los cuales contienen información orientada hacia el documento o información orientada hacia el procedimiento. Las operaciones y los mensajes son descritos de manera abstracta, que luego son ligados a un protocolo concreto de red y aun formato de mensaje para definir el punto final (endpoint). Los WSDL se pueden extender con el fin de hacer una descripción de los puntos finales (endpoints) y sus mensajes sin tener en cuenta que formato de mensaje o que protocolo de red es empleado para comunicarse.[36]
2.2.2.1. Pasos involucrados para proveer y consumir un servicio web
Los pasos involucrados son:[35] 1. El proveedor del servicio describe su servicio empleando WSDL. Esta
definición se publica en el directorio de servicios. El directorio puede usar Universal Description, Discovery, and Integration (UDDI) u otras formas de directorio pueden ser empleadas también.
2. Un consumidor de servicios demanda o solicita uno o más consultas (queries)
hacia el directorio con el fin de localizar al servicio y determinar cómo comunicarse con dicho servicio.
3. Parte del WSDL suministrado por el proveedor del servicio es pasado al
consumidor del servicio. Este WSDL le informa al consumidor del servicio lo que las solicitudes (requests) y respuestas son para el proveedor del servicio.
4. El consumidor del servicio emplea el WSDL para enviar una petición (request)
al proveedor del servicio. 5. El proveedor del servicio suministra la respuesta esperada al consumidor del
servicio.
27
Vistos de manera gráfica los anteriores pasos (ver figura 3), se tiene:
Figura 3. Using the Web Services Description Language (WSDL)
Fuente:http://www.servicearchitecture.com/webservices/articles/web_services_explained.html
2.2.3. Web Map Service (WMS)
Es un Servicio Web que ofrece una interfaz estándar para Servicios Web de Mapas (Web Map Service - WMS) del Open Geospatial Consortium (OGC) para Sistemas de Información Geográfica abiertos (OpenGIS); este estándar provee una simple interfaz HTTP para que los usuarios puedan solicitar la imagen de un mapa Geo-Registrado desde una o más Bases de Datos GeoEspaciales Distribuidas.[37]
28
A través del protocolo WMS se sirven imágenes de forma segura y rápida. Los datos permanecen seguros, ya que se sirven como imágenes renderizadas. A menos que se digitalice encima de las imágenes, no hay forma de copiar los datos originales de las imágenes de los mapas. La apariencia de cada capa de mapa se puede controlar utilizando el estándar SLD que permite definir el color y etiquetado de las features, o geometrías, de las diferentes capas. La combinación de estas reglas con la posibilidad de filtrar estilos dependientes del nivel de escala (filtros OGC), permite ir añadiendo cada más detalle en la visualización de los mapas, a medida que se acerca el zoom a un zona. También es capaz de gestionar amalgamiento de etiquetas, agrupaciones y prioridades de dibujado.[38] Permite enviar datos puramente vectoriales a clientes que implementen el protocolo WFS. Un cliente WFS es capaz de descargar datos vectoriales, que luego pueda utilizar en sus mapas, análisis espaciales y otras operaciones. También, si el usuario tiene autorización, puede enviar de vuelta los datos modificados al servidor, para almacenar en el mismo los datos modificados, utilizando el protocolo WFS-T. Los datos se pueden transmitir utilizando GML (comprimido), así como otros estándares de formatos de datos como shapefile y json.[38] Se pueden enviar datos raster a un cliente utilizando protocolo WCS: Un cliente GIS puede pedir datos raster para utilizarlos en análisis espaciales. Esto permite la creación de aplicaciones que pueden modelar el proceso descrito por sus datos.[38] Reproyección ‘al vuelo’: GeoServer soporta la mayoría de Bases de Datos de proyecciones EPSG y puede reproyectar a cualquiera de ellas bajo petición, lo que permite a las aplicaciones clientes delegar la carga de procesamiento de reproyecciones al servidor.[38] WMS Tiling Cache GeoWebCache es un cliente de tiles WMS. Corre un servidor proxy entre el cliente de mapa y el Servidor de Mapas, cacheando los tiles, a medida que se piden, y consiguiendo una mejora considerable en el tiempo de proceso para la generación de imágenes. GeoWebCache se ha integrado dentro de GeoServer.[38] En la figura 4, se aprecia un ambiente configurado con el servidor de mapas GeoServer, consumiendo y publicando servicios WMS.
29
Figura 4. Web Map Service
Fuente: http://www.opengeospatial.org/standards/wms
2.2.4. Web Coverage Service (WCS).
Es un Servicio Web que ofrece una interface estándar para Servicios Web de Coberturas (Web Coverage Service - WCS) del Open Geospatial Consortium (OGC) para Sistemas de Información Geográfica abiertos (OpenGIS); este estándar provee una simple interface y operaciones que posibilitan la interoperabilidad en el acceso a Coberturas GeoEspaciales [http://www.opengeospatial.org/ogc/glossary/c].
2.2.5. Web Feature Service (WFS).
Es un Servicio Web que ofrece una interfaz estándar para Servicios Web de Coberturas (Web Feature Service - WFS) del Open Geospatial Consortium (OGC) para Sistemas de Información Geográfica abiertos (OpenGIS); este estándar permite interactuar con los mapas servidos por el estándar WMS, como por ejemplo, editar la imagen que nos ofrece el servicio WMS o analizar la imagen siguiendo criterios geográficos.[37]
30
2.3. TELEFONÍA MÓVIL
La telefonía móvil, también llamada telefonía celular, básicamente está formada por dos grandes partes: una red de comunicaciones (o red de telefonía móvil) y los terminales (o teléfonos móviles) que permiten el acceso a dicha red.[39] La distribución física de los recursos se muestra en la figura 5, en esta figura puede apreciar que, la distribución física está compuesta por una arquitectura de “n” capas, en donde y para este caso, n = 3.
Figura 5. Arquitectura Aplicaciones Móviles para Clientes Livianos Internet
Fuente: www.irahul.com/workzone/mobile/04AppArchtecture.pdf
2.3.1. El Concepto de S.I.G. Móvil (Mobile GIS).
Tradicionalmente los Sistemas de Información Geográfica (SIG), son sistemas computacionales que permiten recolectar, simular, procesar, buscar, analizar y describir datos o información geográfica; además, los Sistemas de Información Geográfica (SIG) se pueden tratar como una materia de ciencias de la computación integrada. Ahora bien, desde el punto de vista de los objetos que poseen movimiento, en el estado estático o en el estado de movimiento, se le llama SIG Móvil a la simulación por medio de un sistema de cómputo del espacio y de la referencia de un objeto.[40]
31
2.3.2. Modelo de Datos Espacial S.I.G. Móvil.
Aunque la tecnología SIG surgió hace más de 40 años, el objeto de investigación de los SIG han sido entidades geográficas estáticas. Cómo describir los objetos en movimiento y, las relaciones entre los objetos en movimiento y las entidades geográficas estáticas, es el CORE o núcleo de los problemas de investigación para la tecnología SIG móvil.
Figura 6. Arquitectura S.I.G Móvil.
Fuente: http://www.itc.nl/library/Papers_2007/msc/gfm/delikostidis.pdf
El SIG Móvil, es una aplicación de los SIG y las comunicaciones móviles, las cuales integran GPS, Wireless LBS, comunicación móvil, (como GSM, GPRS, CDMA, etc.) e internet inalámbrico, entre otros. (Ver Figura 6).
32
2.3.3. Arquitectura Distribuida de Cuatro (4) Capas para S.I.G. Móvil
Los protocolos de comunicación empleados entre el nivel de un cliente móvil y el nivel de un servicio web se realiza a través de http/SOAP/OTA. El término Over-The-Air provisioning (OTA), define una manera de encontrar una aplicación de interés en la web, descargarla e instalarla directamente desde una red inalámbrica (wireless network).[41] (Ver Figura 7).
Figura 7. Detalle Sistema OTA.
Fuente: http://developers.sun.com/mobility/midp/articles/ota/ Por medio del protocolo OTA, en el nivel del cliente móvil se descarga e instala el programa o aplicación Java sobre la terminal Móvil, la cual se almacena en el nivel superior del servicio web. Una vez obtenida la aplicación Java en Web del SIG, el cliente se une al nivel del servidor a través de una transacción lógica SIG por medio de un protocolo SOAP o TCP/IP; en este momento el servidor depende de los requerimientos del cliente, adquiere entonces los datos desde el nivel de persistencia (Base de Datos) para luego transmitir la información hacia el lado de la aplicación del cliente, de manera que hace usar al cliente el contenido de los datos SIG desde la Web.[42] (Ver Figura 8).
33
Figura 8. Arquitectura Distribuida en 4 Capas para SIG Móvil.
Fuente: Environmental Informatics Archives, Volume 2 (2004), 920-926 El layer superior busca el Servicio Web (el cual incluye el Middleware y la Base de Datos) por medio de UDDI/WDSL, transmite luego la petición del cliente móvil al Servicio Web en formato SOAP; el servicio web responderá a la petición y enviará el resultado al layer superior; la capa superior traslada entonces, el resultado hacia el lado del cliente móvil.[42] (Ver Figura 9).
Figura 9. Diagrama lógico del SIG Móvil.
Fuente: Environmental Informatics Archives, Volume 2 (2004), 920-926
34
2.4. NUBE COMPUTACIONAL (CLOUD COMPUTING)
La característica básica de la computación en la nube es que los recursos y servicios informáticos, tales como infraestructura, plataforma y aplicaciones, son ofrecidos y consumidos como servicios a través de la Internet sin que los usuarios tengan que tener ningún conocimiento de lo que sucede detrás. Esto debido a que los usuarios no tienen idea alguna sobre la infraestructura que opera para ofrecer los servicios es que se llama Computación en las Nubes.[22] La arquitectura y terminología del Cloud Computing está claramente definida como, básicamente, una nube (Cloud). Cloud Computing es realmente la culminación del uso conjunto de múltiples tecnologías como grid computing, utility computing, SOA, Web 2.0, así como otras. Cloud computing permite desplegar servicios virtualizados y dinámicamente escalables a diferentes niveles, posibilitando la definición de Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) o Software as a Service (SaaS).[43] (Ver Figura 10).
Figura 10. Arquitectura Cloud Computing.
Fuente: Cloud computing: state-of-the-art and research challenges, Qi Zhang · Lu Cheng · Raouf Boutaba. Published online: 20 April 2010.
35
2.4.1. Cloud Computing Framework (Nube Computacional)
Cloud Computing se ha convertido en una frase popular desde el año 2007; sin embargo, aún no hay una definición estándar acerca de que es la Cloud Computing o que es un Sistema Cloud Computing, esto es debido a docenas de organizaciones y desarrolladores que describen Cloud Computing desde diferentes perspectivas. [48] Techterms.com define la Cloud Computing de la siguiente manera: La Cloud Computing se refiere a aplicaciones y servicios ofrecidos en Internet. Estos servicios son ofrecidos desde los DataCenters en todo el mundo, esto se ha llamado de manera colectiva como la Nube (Cloud). Esta metáfora representa la esencia o naturaleza intangible y universal del internet. La idea de la Nube es simplificar la cantidad enorme de conexiones y sistemas de computación envueltos en los servicios en línea (on line). [48] Los Sistemas Cloud Computing pueden ser considerados como una colección de diferentes servicios, de esta manera el framework Cloud Computing se ve como una división de tres capas, las cuales a su vez representan la capa de infraestructura, la capa de la plataforma y, la capa de las aplicaciones tal y como se muestra en la figura siguiente: [47]
36
Figura 11. Framework Cloud Computing.
Fuente: http://www.sciencedirect.com/science/article/pii/S0167739X11001397#f000005
37
2.4.2. Características de la Cloud Computing (Nube Computacional).
De acuerdo con [47] las características de la Nube Computacional son las siguientes: - Virtualización: la nube (cloud) puede considerarse como un conjunto de
recursos virtuales [50] en donde todas las capas inferiores (en la arquitectura) de dispositivos de hardware están virtualizadas. El usuario final accede los recursos que requiere a través de un navegador de internet (browser) obteniendo la información desde el proveedor de la Cloud Computing sin necesidad de realizar el mantenimiento de sus propios DataCenters.
- Confiabilidad, usabilidad y escalabilidad: la Cloud Computing provee un modo
seguro de almacenar datos del usuario de tal manera que, el usuario no debe preocuparse de las particularidades de actualización de la versión del software, re-parcheo de plataforma, ataques de virus o pérdida de información. [47]
- Grandes Escalas: con el fin de poseer la capacidad de supercomputación y
almacenamiento masivo, un sistema Cloud Computing consiste normalmente de cientos de servidores y PCs. [47]
- Sistema Autónomo: los sistemas Cloud Computing son sistemas autónomos
administrados de forma transparente a los usuarios finales. Sin embargo, el software y los datos dentro de la nube pueden ser automáticamente reconfigurados y consolidados en una plataforma simple de acuerdo con las necesidades del usuario final. [47]
2.4.3. Retos de la Cloud Computing (Nube Computacional).
El nuevo paradigma Cloud Computing provee una serie de beneficios y ventajas por encima de otros paradigmas previos de computación, de tal manera que, muchas organizaciones se están moviendo o migrando a este nuevo paradigma de computación. [47]
38
No obstante, existen aún algunos retos, los cuales están siendo encaminados o abordados por investigadores, académicos y profesionales de dicha área; estos retos se pueden describir a continuación: [47] - Rendimiento: el mayor reto es el rendimiento, esto es debido a que las
aplicaciones son orientadas a las transacciones y a que otras aplicaciones que procesan datos intensivamente, en estas la nube Cloud Computing carece de un adecuado rendimiento. Los usuarios que están lejos físicamente de los proveedores de Cloud Computing experimentan retrasos y e intervalos de latencia.
- Seguridad y Privacidad: muchas compañías están preocupadas por la
seguridad cuando utilizan Cloud Computing. Por otra parte, los usuarios están preocupados por la vulnerabilidad a los ataques, cuando la información y los recursos de Information technology (IT) están fuera de la zona militarizada o firewall.
- Control: una gran cantidad de departamentos de IT están preocupados debido
a que los proveedores Cloud Computing tienen el control total de las plataformas. Los proveedores Cloud Computing típicamente NO DISEÑAN PLATAFORMAS para compañías específicas ni para las prácticas de negocio particular de estas compañías.
- Costos en el ancho de Banda: con el paradigma Cloud Computing las
empresas pueden ahorrar dinero en hardware y software, pero deben incurrir en altos costos en redes de banda ancha.
- Confiabilidad: el paradigma Cloud Computing aun no ofrece confiablidad para
algunos usuarios. Existen casos en que los servicios Cloud Computing han sufrido cortes de servicio durante algunas horas. En el presente y futuro se espera que los proveedores Cloud Computing sean más ricos en servicios, y establezcan estándares y buenas prácticas. [49]
39
Cloud Computing ha emergido como un paradigma para entregar servicios por demanda (ej., infraestructura, plataforma, software, entre otros) a clientes de manera similar a otras utilidades del mercado (acueducto, energía y gas). [51] Los tres servicios principales son proveídos por la arquitectura Cloud Computing de acuerdo a las necesidades de los clientes de Information technology (IT). [53]
2.4.4. Modelos básicos de servicio en la nube:
Infrastructure as a Service (IaaS): provee un completo ambiente de despliegue, para correr y administrar de manera virtual maquinas (computadores o servidores) y almacenamiento.
Platform as a Service (PaaS): provee una plataforma para el desarrollo de otras aplicaciones soportadas e implementadas en este servicio; por ejemplo, Google App Engine (GAE). [53]
Software as a Service (SaaS): provee acceso a todas las aplicaciones como servicio, a manera de ejemplo, proveer acceso a los clientes de una empresa a su Customer Relationship Management (CRM).
En el contexto del Consorcio para la Medición del Índice de Servicio Cloud (Cloud Service Measurement Index Consortium - CSMIC), varios retos se han abordado con el objeto de realizar un modelo que permita evaluar la calidad del servicio (QoS) y la clasificación de los proveedores de la Cloud Computing. El primer reto es en relación a “cómo medir los atributos del Índice de Medición del Servicio o en inglés, Service Measurement Index (SMI). Muchos de estos atributos varían en el tiempo, por ejemplo, se ha encontrado que el rendimiento de las máquinas virtuales (Virtual Machine -VM) de Amazon ha cambiado drásticamente y se han alejado de los valores prometidos en los acuerdos de servicio (Service Level Agreemen - SLA). [54] El segundo reto está en cómo clasificar los mejores servicios basados en sus atributos. Existen dos tipos de requerimientos QoS que un usuario puede necesitar: Requerimientos Funcionales y los No Funcionales. Algunos de estos no pueden ser medidos fácilmente debido a la misma naturaleza de la Cloud. [54]
40
Atributos como la seguridad y la experiencia del usuario no son fáciles de cuantificar. Más aun, decidir cuál servicio se ajusta mejor a todos los requerimientos funcionales y no funcionales representa un problema al momento de hacer la decisión. [55] Esta decisión ya pertenece a otro campo de investigación, se trata del problema de Realizar una Decisión Multi-Criterio (Multi-Criteria Decision-Making - MCDM). Cada parámetro de manera individual afecta el proceso de selección de la calidad del servicio e impacta a toda la clasificación del servicio pasando a depender de la prioridad en el proceso de selección del mismo. [56]
2.4.5. Medición del Servicio (Service Measurement Index - SMI).
Los atributos del SMI se diseñan por el Consorcio para la Medición del Índice de Servicio Cloud (Cloud Service Measurement Index Consortium - CSMIC), estos se diseñan basados en los estándares ISO (International Organization for
Standardization - ISO). Esta medición consiste en un conjunto de llaves de Indicadores de Rendimiento como llaves de negocio relevantes (Performance
Indicators - KPIs) los cuales proveen métodos estandarizados para la medición y comparación de servicios empresariales. [55] El marco de referencia (Framework) del SMI provee una visión holística de las necesidades de los clientes por la Calidad del Servicio (QoS), este ayuda a seleccionar un proveedor de servicio Cloud basado en: [55]
a. Rendición de cuentas; b. Agilidad; c. Garantía del servicio; d. Costo del servicio; e. Rendimiento; f. Seguridad; g. Privacidad; h. Usabilidad.
41
Actualmente, no existen métodos o métricas disponibles públicamente que definan perfectamente estos KPIs y comparen eficientemente a los proveedores de servicio Cloud; hasta ahora, el SMI es el pionero en esta dirección.
2.4.6. Arquitectura SMICloud (Service Measurement Index - SMI).
Dentro del contexto de [55], se propone un marco de referencia para la Medición del Índice de Servicio Cloud llamado SMICloud. Este marco de referencia ayuda a los clientes de la Nube Computacional a encontrar al proveedor de servicio Cloud más adecuado y por tanto, poder negociar los Acuerdos de niveles de Servicio (Service Level Agreemen - SLA). Este framework se elige puesto que, por ejemplo, para una empresa del Distrito Capital de Bogotá como la Empresa de Acueducto y Alcantarillado de Bogotá (E.A.A.B.-E.S.P), es muy importante acordar y definir sus SLAs en las áreas de tecnología y específicamente para los outsourcing de servicios tecnológicos. Actualmente, el Distrito Capital de Bogotá está en sintonía con la política del Ministerio de Tecnología de la Información y las Comunicaciones (MinTIC) con el plan “Vive Digital” y para ello, ha solicitado a las entidades del estado y en particular, a las entidades del Distrito Capital alinearse con esta política e innovar o migrar su infraestructura tecnológica hacia la Cloud Computing. Sin embargo, muchas entidades del Distrito Capital no cuentan con la experiencia ni los instrumentos ni los métodos para alinearse con esta política y mucho menos, para decidir cuál es el mejor proveedor de servicios TIC o el mejor proveedor de servicios Cloud Computing Apoyado en el SMICloud Framework, se propuso y se lidero un acercamiento entre la Universidad Distrital F.J.C. y la EAAB con el fin de, suscribir un acuerdo dentro del “CONVENIO MARCO DE COOPERACION ENTRE LA EMPRESA DE ACUEDUCTO Y ALCANTARILLADO DE BOGOTÁ E.A.A.B – E.S.P Y LA UNIVERSIDAD DISTRITAL FRQANCISCO JOSE DE CALDAS” con el único objetivo de evaluar cuál es el mejor proveedor de servicios de TI o cual es la mejor opción en cuanto a proveedor de servicios Cloud Computing y reducir la brecha existente entre el plan “Vive Digital” del Ministerio de Tecnología de la Información y las Comunicaciones (MinTIC) y la realidad de nuestro país.
42
El SMICloud Framework provee características como, la selección del servicio basado en los requerimientos de calidad (QoS) de los clientes y en la clasificación de servicios soportados en la en la experiencia previa y en el rendimiento de dichos servicios. El SMICloud Framework es una herramienta para la toma de decisiones, diseñada para obtener la valoración de los servicios Cloud en términos de KPIs y requerimientos de usuario. Los clientes del servicio proveen dos categorías para el requerimiento de las aplicaciones: Requerimientos esenciales y los no esenciales. [55] - Requerimientos Esenciales: permiten al cliente especificar cuál será el
mediador, es decir, si un cierto atributo del SMI no satisface el nivel requerido en términos de las necesidades de los clientes, el servicio será inaceptable independientemente de cómo estén valorados los demás atributos.
- Los Requerimientos no Esenciales son por ejemplo, para un usuario académico, el nivel de seguridad no es esencial, si su proyecto no tiene fines comerciales.
Figura 12. SMICloud Framework.
Fuente: http://www.sciencedirect.com/science/article/pii/S0167739X11001397#f000005
43
Basado en estos requerimientos, SMICloud proporciona una lista de servicios Cloud los cuales pueden emplear los clientes con el fin de desplegar sus aplicaciones. La figura anterior, muestra los componentes clave del Framework. [57]
2.4.6.1. SMICloud Broker
Este componente es el responsable por la interacción entre los clientes y la comprensión de las necesidades de sus aplicaciones. Este componente recolecta todos sus requerimientos y ejecuta descubrimiento y clasifica los mejores servicios empleando otros componentes empleando SMICalculator y sistemas de clasificación.
2.4.6.2. Monitoring:
Este compoenete primero descubre servicios Cloud que puedan satisfacer los requerimientos esenciales de calidad del usuario. Luego este componente monitorea el rendimiento de los servicios Cloud, por ejemplo para un IaaS la velocidad de las VMs, monitorea la memoria, el crecimiento de la latencia, el rendimiento en el almacenamiento, latencia en la red y disponibilidad de banda ancha. Además, guarda una historia de cómo han sido los requerimientos previos en los SLAs para el usuario.
2.4.6.3. Service Catalogue:
Almacena los servicios y sus características anunciados por diferentes proveedores Cloud.
44
2.4.7. Clasificación del Servicio Cloud.
La característica más importante del SMICloud Framework es la clasificación de los servicios Cloud. El sistema de clasificación calcula valores relativos de clasificación de los servicios Cloud basados en los requerimientos de calidad (QoS) del cliente y basado en las características de los servicios Cloud. [57]
Figura 13. Analytical Hierarchical Process (AHP).
Fuente http://www.sciencedirect.com/science/article/pii/S0167739X11001397#f000005 Con el fin de resolver el problema de clasificación de los servicios Cloud, [57] propone el Proceso Jerárquico de Análisis (Analytical Hierarchical Process - AHP).
45
El sistema de clasificación toma en cuenta cosas antes de decidir desde donde se arrendaran los recursos Cloud:
a. La primera es, clasificación de la calidad del servicio está basado en el Proceso Jerárquico de Análisis (Analytical Hierarchical Process - AHP).
b. La segunda es, clasificación final basada en el costo y calidad de la
clasificación. En términos generales, el AHP descompone un problema de toma de decisión en partes continuas construyendo jerarquías con criterios similares de KPIs sobre el framework SMI. [56] AHP ayuda a capturar tanto medidas de evaluación subjetivas como medidas objetivas, proveyendo un mecanismo poderoso para la validación de la consistencia en la evaluación de alternativas y medidas, AHP reduce la parcialidad en la toma de decisiones. [57] El Proceso Jerárquico de Análisis (Analytical Hierarchical Process - AHP) basado en acercamientos como CloudGenius [14] y basado en el SMICloud [16] requiere que el usuario provea un esquema de pesos para los parámetros asignados para que los usuarios entonces puedan emplear con el fin de ordenar sus soluciones. Esto conlleva al Sistema que Soporta la Decisión de la Migración (MIGRATION
DECISION SUPPORT SYSTEM - MDSS), este se enfoca en permitir a los usuarios que definan el criterio que dinámicamente clasificara los resultados basados en el costo o en cualquiera de los otros parámetros. De esta manera, la capacidad de la optimización multicriterio se soporta en el AHP basado en acercamientos negociando con el que requiera menos interacción con el usuario, resultando en fácil de usar para el usuario. [16]
46
2.5. APLICACIÓN SOA A LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA.
Una vez definida la arquitectura Service-oriented architecture (SOA), y comprobado que por definición es capaz de integrar diferentes herramientas a través del Enterprise Service Bus (ESB), independientemente de la licencia del software (libre o propietario), se aplicará un ejemplo de implantación SOA en el entorno de los sistemas de información geográfica. La arquitectura presenta tantas ventajas para la problemática habitual de los SIG que ningún proyecto de información geográfica debería comenzar sin evaluar seriamente la opción de enfocarlo desde una perspectiva orientada a servicios. Una de las políticas de los grandes Sistemas de Información Geográfico empresariales, debiera ser la implementación de una estrategia de integración de todas sus aplicaciones a través de la exposición de todas sus funcionalidades como servicios web e implementar una sola aplicación que orqueste este conjunto de servicios. (Ver Figura 14).
Figura 14. Sistema sencillo basado en servicios.
Fuente:http://www.geograma.com/es/publicaciones/arquitectura-soa-para-la-integraci-n-entre-software-libre-y-software-propietario-en-entornos-mixtos.html
47
Hoy en día, con la globalización y la expansión geográfica de actividades humanas, se están empleando dimensiones espacio-temporales para almacenar de una mejor forma estos cambios relacionados con la espacialidad. De manera colectiva, se han acumulado exabytes de registros de datos y, estos set de datos (DataSets) han incrementado a una velocidad de petabytes diariamente. [8] Aun con las tecnologías del siglo 21, las Ciencias Geoespaciales tienen aún grandes retos en la tecnología de la Información (IT), especialmente con respecto a intensidad en el procesamiento de los datos, intensidad de computación, intensidad de concurrencia e intensidad espacio-temporal. [6] Estos datos geoespaciales se han recolectado y se han archivado en distintas ubicaciones los cuales registran múltiples fenómenos de múltiples regiones y de múltiples escalas. En las prácticas de compartir datos, lo cual es requerido en los estudios de fenómenos de la tierra, presenta grandes retos en la organización y administración de contenido de datos, formato de los datos y descubrimiento de datos, acceso y utilización de los datos. [11] Otro aspecto a tener en cuenta es, no es posible para cada organización o usuario final adquirir infraestructura computacional de alto rendimiento. Con la intención de conducir la investigación científica y mejores aplicaciones Cloud, se necesita de tecnologías de la computación que posibiliten reutilizar e incluir detalles más esenciales para los modelos que simplifiquen dicha computación. Los estudios muestran que si el tiempo de respuesta es más largo de tres (3) segundos, los usuarios se sentirán frustrados. Con el incremento del número de sistemas geoespaciales en línea, como tráfico en tiempo real, respuestas de emergencias, búsquedas de casas inmobiliarias, avances en las cyberinfraestructuras y otros servicios basados en Frameworks de datos, se esperan muchos más servicios en línea más populares sumando accesos concurrentes de manera masiva como características de las aplicaciones y las ciencias geoespaciales del siglo 21. [3]
48
Esta visión posee grandes oportunidades y grandes retos para dar importancia a los dominios científicos y tecnológicos, como ancho de banda, computación clúster, privacidad, seguridad, confiabilidad, ítems de gran relevancia para los sistemas y la información y otros que debe enfrentar de manera masiva los usuarios. [58] En los estudios de importancia en las geociencias, tales como ciencias oceánicas y atmosféricas, el espacio-tiempo y la geodinámica han sido siempre el núcleo de los dominios de dicha investigación. Este núcleo de investigación se ha convertido en crítico en casi todos los dominios del conocimiento humano. [59] Reconociendo estos problemas y capacidades geoespaciales, la comunidad global reconoce que es algo crítico compartir observaciones de las ciencias de la tierra y recursos relevantes con el propósito de encaminar los retos globales. Más de 140 países colaboran para conformar el Grupo Intergubernamental de Observaciones de la tierra (Group on Earth Observations - GEO) y han propuesto una solución sistema de sistemas.
Figura 15. Solución Sistema de Sistemas
Fuente: http://cisc.gmu.edu/scc/readings/spatial_cloud_computing.pdf
49
En ésta solución o proceso está envuelto desde la computación de mainframes, computación de escritorio, computación en red, computación distribuida, computación GRID y otros tipos de computación. [60] La tecnología de computación GRID inicio en la comunidad científica, esta se empleó para el despliegue a grandes escalas de computación distribuida Ahora bien, con la aparición de la computación en la Nube (Cloud Computing), se logra brindar potentes soluciones para resolver el problema de intensidad geoespacial (datos) gracias al paradigma de elasticidad y acceso por demanda de manera masiva a recursos de computación instanciables y asequibles. [61] Las ciencias Geoespaciales en el siglo 21 pueden también contribuir con los estudios de espacio-temporales con el fin de optimizar la computación en la nube. Con el objeto de capturar las relaciones intrínsecas entre la Cloud Computing y las ciencias geoespaciales, se introduce ek termino de Spatial Cloud Computing (SCC) para: [62]
1. Posibilitar la resolución de problemas de las ciencias geoespaciales para los cuatro problemas de intensidad (intensidad en el procesamiento de los datos, intensidad de computación, intensidad de concurrencia e intensidad espacio-temporal).
2. Facilitar la implementación de la Cloud Computing y asegurar la
combinación de elasticidad, acceso por demanda y otras características de la Cloud Computing.
El Instituto Nacional de Estándares y Tecnología (National Institute of Standards
and Technology - NIST) definió la Cloud Computing como: “… un modelo que posibilita convenientemente el acceso por demanda a la red a recursos de computación configurables y compartidos (p.ej: redes, servidores, almacenamiento, aplicaciones y servicios) que pueden ser rápidamente aprovisionado y liberado con un mínimo de esfuerzo en la administración o en la interacción del proveedor del servicio. [63]
50
Como la Cloud Computing está prevista para tener de manera conveniente, consumo eficiente de energía y presupuesto, el gobierno de los Estados Unidos solicito a todas sus agencias de estado que para los próximos años siguientes, se deben migrar hacia la Cloud Computing o sustentar el por qué no se migraran a la Cloud Computing, esto será por consiguiente, el futuro de la infraestructura computacional que soportara las ciencias geoespaciales. [64]
2.5.1. Servicio Cloud Computing para las Ciencias Geoespaciales:
En las ciencias Geoespaciales, la Nube Computacional se proporciona a través de al menos cuatro tipos de servicios:
- Infrastructure as a Service (IaaS) - Platform as a Service (PaaS) - Software as a Service (SaaS) - Data as a Service (DaaS)
Los tres primeros son definidos por el Instituto Nacional de Estándares y Tecnología (National Institute of Standards and Technology - NIST), el cuarto modelo de servicio Cloud Computing DaaS es esencial para las ciencias geoespaciales. Estos cuatro modelos de servicio son referidos como Everything as a Service (XaaS). [64]
2.6.1.1. Infrastructure as a Service (IaaS)
este es el servicio Cloud más popular, este entrega infraestructura de computación, incluyendo maquinas físicas, redes, almacenamiento y sistemas de software. IaaS brinda la posibilidad a los usuarios de configurar, desplegar, y correr sistemas operativos (OS) y aplicaciones basadas en OS. El producto comercial más notable es el Amazon Elastic Compute Cloud (EC2, http://aws.amazon.com/ec2/). [65]
51
2.6.1.2. Platform as a Service (PaaS)
Este es un servicio de más alto nivel que IaaS y este proporciona una plataforma como servicio para que los desarrolladores de software construyan aplicaciones. En adición a la plataforma computacional, PaaS provee una capa de software basada en la Cloud e interfaces de Programación de Aplicaciones (Application
Programming Interface - API) que pueden ser empleadas para construir servicios de alto nivel. Microsoft Azure (http://www.microsoft.com/windowsazure) y Google
App Engine son los ejemplos más notables de PaaS. [65]
2.6.1.3. Software as a Service (SaaS)
Este es el tipo de servicio más usado de Cloud Computing puesto que provee varias capacidades de aplicaciones sofisticadas que son tradicionalmente proveídas a través de los navegadores web hacia los usuarios finales. Los ejemplos más notables de estas aplicaciones son Salesforce.com y las aplicaciones de gmail de Google (http://www.google.com/apps/). La implementación de ArcGIS en la Cloud es otro ejemplo de SaaS espacial. [65]
2.6.1.4. Data as a Service (DaaS)
De los cuatro tipos de servicios en la nube, DaaS es el menos definido. Este soporta descubrimiento de datos, acceso, utilización, despliegue y procesamiento de datos por demanda para usuarios finales de manera independientemente de la organización o ubicación geográfica del proveedor y del consumidor. [66] Esto esta soportado por una capa o layer de integración intermedia que proporciona datos y procesamiento y a su vez optimiza las operaciones en la Cloud. DaaS es capaz de facilitar el descubrimiento de datos, la accesibilidad y utilizabilidad al vuelo con el fin de soportar la gran demanda en las ciencias. En la actualidad, se están desarrollando DaaS basados en muchas plataformas Cloud. [67]
52
2.6. CLOUD COMPUTING ESPACIAL - SPATIAL CLOUD COMPUTING (SCC)
La nube computacional o Cloud Computing se ha convertido en la siguiente generación de plataforma computacional y, el gobierno de los Estados Unidos está promoviendo su adopción para reducir los arranques, el mantenimiento y los costos del consumo de energía. [68] Colombia, al igual que el mundo entero, no está ajena a estas políticas de Tecnologías de la Información, el Ministerio de Tecnologías de la Información y las Comunicaciones también se aliena y propone dentro de sus planes contempla una etapa de implementación de Nube Computacional: “Al iniciar el Siglo XXI se evidencia una utilización masiva de equipos móviles,
tabletas, cloud computing -computación en la nube-, y virtualización de escritorios,
que hacen posible la movilidad y el acceso en cualquier momento y desde
cualquier lugar a los sistemas de información de la empresa, lo cual facilita los
procesos de la organización.” (http://www.mintic.gov.co/index.php/teletrabajo2/iniciativa). En el Distrito Capital de Bogotá, también existe una política de actualización de las entidades del Distrito Capital en el sentido de disminuir la brecha tecnológica y optar por modelos o paradigmas vigentes como la Nube Computacional. "...se pretende realizar el análisis y diseño para la construcción de la plataforma para la gestión y disposición de recursos geoespaciales de la administración distrital bajo un entorno Cloud Computing, que incluya una identificación detallada de requerimientos funcionales y no funcionales, el diseño de una arquitectura tecnológica basada en SOA que represente recursos técnicos y procesos, y la creación y validación de un modelo de datos para el almacenamiento de la información geográfica..." (http://www.ideca.gov.co/index.php?q=es/content/plataforma-geoespacial-para-la-gesti%C3%B3n-y-disposici%C3%B3n-de-datos-servicios-y-aplicaciones-del-d)
53
En el contexto de [62], Spatial cloud computing se refiere al paradigma de nube computacional que es direccionado por las ciencias Geoespaciales y, optimizado por los principios espacio-temporales con el objeto de posibilitar el descubrimiento en las ciencias geoespaciales y posibilitar el paradigma Cloud Computing con ambientes de computación distribuida.
Figura 16. Framework Spatial Cloud Computing
Fuente: http://dx.doi.org/10.1080/17538947.2011.587547
La Nube Computacional Espacial - Spatial Cloud Computing (SCC) es representada como un marco de referencia o Framework que incluye una infraestructura computación física, recursos computacionales distribuidos en múltiples ubicaciones y un servidor virtual SCC que administra los recursos que soporta los servicios Cloud para los usuarios finales. [62]
54
En la figura del Framework Spatial Cloud Computing los componentes en color azul están capacitados para optimizar con los principios espacio-temporales el aseguramiento de las cinco características de la Nube Computacional. El servidor virtual podrá: [62]
1. Provee la funcionalidad de virtualización y soporte de máquinas virtuales sobre las maquinas físicas con los más importantes capacidades tecnológicas de la Cloud Computing.
2. Optimiza las capacidades de red para proveer de la mejor forma y automatizar las IPs públicas y privadas y los nombres de dominios basados en el uso dinámico de recursos computacionales con capacidad espacio-temporal.
3. Determinar cuál maquina física emplear cuando un servicio Cloud es requerido, basándose en políticas y horarios optimizados para los principios espacio-temporales.
4. Mantenimiento de la habilidad espacio-temporal, la localización espacial, y las características de recursos computacionales de memoria comunicando, monitoreando y administrando los recursos computacionales físicos de forma eficiente.
5. Automatizar la escalabilidad y el balanceo de cargas de las instancias computacionales basadas en el criterio de satisfacción del usuario y patrones espacio-temporales de los recursos de computación. [68]
6. Conectar a recursos públicos de Cloud tales como Amazon EC2, para construir Nubes Computacionales Hibridas para servir múltiples necesidades Cloud y asegurar de esta manera las cinco características de la Cloud Computing.
El núcleo del ambiente SCC busca optimizar los recursos computacionales a través de una capa intermedia o Middleware con los principios espacio-temporales y soportar las Ciencias Geoespaciales, basado en las capacidades de la plataforma Cloud Computing, se pueden implementar las funciones núcleo de los Sistemas de Información Geográfica como, re-proyección al vuelo, análisis espacial, entre otras. [62] Dentro de los trabajos futuros en investigación, se hace necesario alinear con los tipos de servicio Cloud Computing, IaaS, PaaS, SaaS y DaaS, implementar una comunicación bilateral entre las ciencias geoespaciales y la Cloud Computing.
55
2.7. NIMBUS, CLOUD COMPUTING PARA LA CIENCIA.
Como el presente proyecto de investigación trata de propondrá y desarrollará un modelo de accesibilidad móvil en la Nube Computacional, se tomara como herramienta fundamental para la publicación y consumo de servicios geográficos en la nube computacional el software NIMBUS. Este es un conjunto de herramientas de código abierto (Open Source), todas sus herramientas en conjunto proveen una solución “Infrastructure-as-a-Service (IaaS) Cloud Computing”, es decir, una solución para la implementación de la Infraestructura como Servicio. El objeto de NIMBUS es, desarrollar la infraestructura con énfasis en las necesidades científicas, teniendo en cuenta que aunque muchos casos de uso no son para aplicación de la ciencia, también son bien soportados por NIMBUS. [23]
Figura 17. Vista general configuración Cloud
Fuente: http://www.nimbusproject.org/docs/current/faq.html
56
NIMBUS permite a los clientes liberar recursos de forma remota desplegando máquinas virtuales Virtual Machines (VMs) sobre esos recursos, permite además, desplegar los recursos de tal manera que representen el ambiente virtual deseado por el usuario. Esto es conocido formalmente como "Virtual Workspace Service" (VWS), sin embargo, el "workspace service" técnicamente es solo uno de los componentes de toda la colección de software.[23] (Ver Figura 17).
2.7.1. Arquitectura NIMBUS Cloud Computing.
� El sitio de administración (Workspace Service site manager): Es un sitio
standalone, administrador de las VM las cuales pueden ser invocadas de manera remota por diferentes protocolos. [23]
� A WSRF based remote protocol implementation: Protocolo de implementación empleado por el Workspace Service y los clientes y empleado por los populares clientes-cloud (cloud-client). [23]
� An Elastic Compute Cloud (EC2) based remote protocol implementation of their SOAP and Query APIs (partial): Esta es una implementación de las dos interfaces Elastic Compute Cloud de Amazon, las cuales permiten emplear clientes desarrollados por sistemas reales EC2 contra nubes basadas en NIMBUS. [23]
� Cumulus: Es una implementación de código abierto (open source) del API REST Amazon S3. Esto es empleado como la solución para el repositorio de NIMBUS y puede ser instalado también de manera autónoma (standalone). [23]
� The RM (site resource management) API: Es el puente entre el protocolo remoto de seguridad (protocols/security) y la implementación especifica del sitio de administración. [23]
� The cloud client: Permite a los usuarios conectarse y correr aplicaciones en unos pocos minutos con las instancias configuradas con solo un click. [23]
� The reference client: Expone todas las características en el protocolo WSRF como un cliente de consola de comandos (with underlying Java client library). Para usuarios avanzados, permite scripting, integración de portal, etc. [23]
� The Workspace Pilot: Permite integrar las VMs con los recursos ya configurados con el fin de administrar los procesos (jobs). [23]
57
� The workspace-control: Es un agente que implementa VMM y las tares de
red especificas en cada hypervisor. [23] � The Context Broker: Permite a los clientes coordinar enormes clusters
virtuales que se lanzan de forma automática y de manera repetitiva. [23] � The Context Agent: reside en las VMs e interactúa con el Context Broker en
el sector del boot de la VM. [23]
2.8. NASA-NEBULA CLOUD COMPUTING.
NEBULA es un proyecto de investigadores de la NASA, con el objetivo de liberar software de código abierto (open source) para proporcionar servicios Cloud Computing a los ingenieros y científicos de la NASA. [24] El objetivo del proyecto es reducir costos centralizando el hardware, empleando software de código abierto y libre, trasladando de esta manera los costos de los investigadores de la NASA hacia las cuentas que se inscriban por pagar. (Ver Figura 18).
Figura 18. Arquitectura NEBULA Cloud Computing
Fuente: http://www.opennebula.org/documentation:uc4
58
Sin embargo y aunque NEBULA está desarrollado sobre código libre y abierto, se debe pagar por cada cuenta que se desea suscribir con el proyecto NASA-NEBULA.
2.8.1. Arquitectura NEBULA Cloud Computing.
Con el fin de desplegar esta arquitectura virtual se recomienda emplear los siguientes componentes: (Ver Figura 19). Nginx Server. Es un balanceador de cargas (load balancer), con el fin de distribuir los requerimientos hacia a los servidores web. Nginx Servers. Son los nodos del balanceador de cargas, configurado como servidor web y se ejecuta sobre las máquinas virtuales. Estos servidores proveerán la capacidad para este caso de uso. Además, se debe implementar las siguientes características: Las máquinas virtuales pueden ejecutarse como servidores web locales (ejecutándose como un hypervisor Xen (atop Xen hypervisor) en la infraestructura local, o ejecutarse como servidores web de manera remota como instancia EC2. La administración (monitoreo, despliegue, migración, etc.) de la máquina virtual se hace a través de OpenNebula
Figura 19. Características NEBULA Cloud Computing
Fuente: http://www.opennebula.org/documentation:uc4
59
2.9. NUBE COMPUTACIONAL MÓVIL (MOBILE CLOUD COMPUTING)
La idea básica de la nube computacional móvil (Mobile Cloud Computing) es mover tanto el almacenamiento como el procesamiento desde los dispositivos móviles de los usuarios hacia la nube computacional (Cloud Computing).[45] Existen algunos ejemplos de aplicaciones de la nube computacional móvil (Mobile Cloud Computing) como Mobile Gmail y Google Maps, sin embargo, muchas de las aplicaciones móviles de hoy por hoy aun emplean tanto el almacenamiento y el procesamiento sobre los dispositivos móviles de los usuarios.[45] (Ver Figura 20). Cuando se mueve la computación móvil tradicional hacia la Cloud, existen algunos ítems que se deben resolver como la eficiencia de la energía, la seguridad y los servicios de la nube computacional móvil (Mobile Cloud Computing).
Figura 20. Cloud Computing bajo tecnología Internet Móvil
Fuente: http://en.sky-mobi.com/technology-cc.html
60
2.9.1. Estado del Arte nube computacional móvil (Mobile Cloud Computing).
Las dos características principales de la nube computacional móvil (Mobile Cloud Computing) son las siguientes: [44] La Cloud Computing posibilita de manera conveniente, el acceso por demanda a la red de un pool de recursos computacionales (redes, servidores, almacenamiento, aplicaciones, servicios, entre otros) configurados de tal manera que rápidamente se puede liberar, con un mínimo de esfuerzo en la administración o interacción, servicios web y para el caso en particular, servicios web geográficos con base en estos recursos de forma ágil. [44] Como se mencionó con anterioridad, existen cuatro (4) modelos básicos de servicio en la nube:
• Infrastructure as a Service (IaaS) • Platform as a Service (PaaS)
• Software as a Service (SaaS)
• Data as a Service (DaaS)
La definición de la nube computacional móvil (Mobile Cloud Computing) fue introducida el 05 de Marzo de 2010, como la habilidad de la nube computacional de servicios en un ecosistema móvil. Esto implementa muchos más elementos como consumidores, grandes empresas, femtocells (en telecomunicaciones es una estación base pequeña celular, desarrollada para pequeños negocios) transcoding (en telecomunicaciones es la conversión directa digital-a-digital desde un encoding a otro) la seguridad del punto final a punto final y servicios de banda ancha.
61
2.9.2. Nube Computacional Vs Nube Computacional Móvil:
En el contexto de [69] sostiene que: “se ofrecen diferentes utilidades computacionales que se distinguen en el nivel de abstracción que presentan al programador y al nivel de abstracción en la administración de los recursos.” Un ejemplo de los proveedores existentes de Cloud, una instancia de EC2 de Amazon, es más una maquina física que permite con un API ligera, casi un total control del software al usuario final de la Cloud. Esto le da al usuario una gran flexibilidad para la codificación de aplicaciones; sin embargo, esto significa que, Amazon presenta poca escalabilidad y presenta características en la recuperación de fallos. En contraste, el motor de aplicaciones Google (Google’s App Engine) obliga a instalar un API en el cliente pero ofrece una impresionante escalabilidad y opciones de recuperación de fallos. Cada uno de los citados proveedores presenta diferentes opciones de computación virtualizada, almacenamiento y comunicación. [69]
2.10. DEFINICIÓN NUBE COMPUTACIONAL MÓVIL (MOBILE CLOUD COMPUTING).
Existen muchas definiciones de Mobile Cloud Computing, y diferentes investigaciones aluden diferentes conceptos de Mobile Cloud: El termino Mobile Cloud Computing, significa correr una aplicación como Google’s Gmail for Mobile en un servidor rico de recursos remotos (para el ejemplo, servidores de Google), tal como se muestra en la figura de abajo. [70]
62
Figura 21. Servidor Remoto Cloud abasteciendo Dispositivos móviles a través de internet
Fuente: http://www.google.com/mobile/mail/ En esta arquitectura mientras que el dispositivo móvil actual como un cliente liviano conectándose sobre un servidor remoto a través de la red 3G. Otros ejemplos de este tipo de servicios son los servicios de localización o ubicación de Facebook, Twitter for mobile, widgets móviles con el estado del tiempo [70], entendiéndose widgets como objetos de código propios de los APIs de programación para móvil como Android, Flex, entre otras. Otro acercamiento es, considerar a otros dispositivos móviles a ellos mismos como proveedores de recursos de la Cloud configurando una red móvil peer-to-peer. [71], En adición, los recursos colectivos de varios dispositivos móviles en la vecindad local con otros dispositivos no móviles si están disponibles, se utilizarán como se muestra en la figura abajo. [71]
63
Figura 22. Recurso Virtual Cloud configurado con dispositivos móviles vecinos
Fuente: http://www.google.com/mobile/mail/ El concepto de Cloudlet propuesto por Satyanarayanan [72] es otro acercamiento a la Nube Computacional Móvil, como se ilustra en la figura abajo: Figura 23. Dispositivo móvil habilitado Cloudlet para omitir la latencia y problemas de banda ancha
y beneficiarse de estos recursos
Fuente: http://www.plugcomputer.org/
64
Este acercamiento ilustra al dispositivo móvil descargando su sobre carga de trabajo en un Cloudlet compuesto de muchos computadores con múltiples cores con conexión a servidores Cloud remotos. Plugcomputer es considerado como un buen candidato para los servidores Cloudlet debido a su forma, diversidad y bajo consumo de energía. [72] Esta arquitectura es similar a las arquitecturas configuradas con computadores normales, la diferencia es que esta es menos poderosa, es más pequeña, menos costosa, ideal para configurar servidores a escala pequeña instalados en infraestructuras públicas. De acuerdo con Satyanarayanan los Cloudltes son computadores confiables ricos en recursos en las cercanías o en la vecindad del usuario móvil (p.ej: cerca de él o con un punto de acceso inalámbrico). En estos Cloudlets los usuarios móviles pueden instanciar muy rápidamente máquinas virtuales personalizadas (VMs) sobre los Cloudlets ejecutando el software requerido en un cliente liviano. Figura 24. Cloudlets Estáticos provisionado por una corporación o un Cloudlet Ad hoc provisto por
una red casera
Fuente:http://lewisshepherd.wordpress.com/2009/12/13/why-a-cloudlet-beats-the-cloud-for-mobile-apps/
65
2.11. TAXONOMIA DE LA NUBE COMPUTACIONAL MOVIL.
En el contexto de [73], se presenta una taxonomía de los acercamientos actuales en la investigación de la Nube Computacional Móvil (Mobile Cloud Computing) basados en elementos como operatividad, niveles de servicio, usuarios finales, seguridad y administración de datos como se muestra en la figura abajo.
Figura 25. Una Taxonomía de los ítems Mobile Cloud Computing
Fuente:http://idpcc.dcti.iscte.pt/docs/Papers_1st_Doctoral_Workshop_15-6-2011/RuiEsteves.pdf Como se muestra en la figura arriba, en la cima de la taxonomía están los elementos que se aplican a muchas áreas y no solamente al área de Mobile Cloud Computing. Estas similitudes con otras áreas, ayuda a dar una comparación de como la Nube Computacional Móvil se relaciona con otros campos. Cada elemento muestra cómo ha sido abordado los retos de Mobile Cloud Computing en trabajos actuales.
66
3. DATOS, METODOS E INSTRUMENTOS
3.1. INTRODUCCION
La Universidad Distrital a lo largo de su historia académica ha participado en los avances científicos de las disciplinas que aloja y desarrolla, en el campo geoespacial ha aportado en diversos aspectos, uno de sus últimos logros en este aspecto se relaciona con la participación en las infraestructuras de datos espaciales relacionadas con la ciudad de Bogotá.
Dentro del desarrollo académico y en especial en los niveles investigativos se hace necesaria la generación de propuestas de aplicación, el presente trabajo de investigación, busca la generación de una propuesta para el diseño y adopción (modelo) de un nodo de Infraestructura de Datos Espaciales, de forma tal que este sea punto de partida para generar y gestionar de datos espaciales. El trabajo de investigación presenta y detalla cada uno de los componentes de la arquitectura, la cual se traduce en un Modelo de Accesibilidad a Servicios de Información
Geográfica en la Nube Computacional partiendo de las políticas, relacionadas con los posibles lineamientos a seguir, los estándares y los metadatos; adicionalmente se definen los elementos de la arquitectura Cloud Computing que soportara el diseño, los roles y responsabilidades del nodo actor para el prototipo computacional experimental.
Por último, se plantea la arquitectura que se traduce en un modelo de accesibilidad a servicios de información geográfica en la nube computacional, el cual integrara el nodo con el resto de los integrantes de la IDE del Distrito Capital; este trabajo de investigación aportara la forma en que dicho componente contribuirá al desarrollo de la ciudad y cómo podrá soportar procesos institucionales como la EAB, el IDEAM, la CAR entre otros, con insumos provenientes de dichos miembros. El presente documento en general busca, ser un punto de partida para la inserción de la Universidad Distrital en la Infraestructura de Datos Espaciales del Distrito Capital como miembro activo y con capacidad de liderazgo e investigación.
67
3.2. RESUMEN EJECUTIVO
Con respecto a los GeoServicios, el proyecto de investigación nace como iniciativa de integrar la Infraestructura de Datos Espaciales del Distrito Capital con el CECAD de la Universidad Distrital Francisco José de Caldas y, surge al existir la necesidad de tener herramientas virtuales (Nube) que permitan el acceso a la GeoInformación para gestionar y controlar una red de información GeoEspacial. Por tal motivo, Se decidió proponer un Modelo de Accesibilidad Móvil a Servicios de Información Geográfica en la Nube Computacional con tecnología ESRI basada en portal, la cual permite compartir recursos geográficos y trabajar en un ambiente colaborativo en una gran red de información (NODO). Ver sección 3.2.1
El proyecto de investigación desarrolla un Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional o “NODO” que actúa como una puerta de entrada a la Universidad Distrital F.J.C. vía web con el fin de facilitar su utilización constituyendo así la capa de aplicación del NODO dentro de una Infraestructura de Datos Espaciales en la Universidad Distrital F.J.C. Para el desarrollo del Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (NODO) y del portal se implementaran estándares que permiten la interoperabilidad entre diferentes NODOS con el objetivo de compartir e integrar recursos de la Universidad Distrital F.J.C y facilitando el acceso a los GeoServicios en la IDE dl Distrito Capital. Para el Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional será necesario aplicar estándares que constituyen hoy por hoy las implementaciones de Geoportales y su relación con servicios web para el habilitamiento de los GeoServicios en la web como los estándares establecidos por el Open Geospatial Consortium (OGC). Finalmente, el perfeccionamiento de este Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (NODO) será un soporte o punto de partida para que la Universidad Distrital F.J.C pueda integrarse e interoperar con la Infraestructura de Datos Espaciales del Distrito Capital en un nivel local y posteriormente a nivel Nacional.
68
3.3. ESTÁNDARES PARA EL NODO IDE DE LA UNIVERSIDAD DISTRITAL
3.3.1. Lineamientos para la Política de Información Geográfica de la
Universidad Distrital
La Universidad Distrital “Francisco José de Caldas” como representante de la institucionalidad Distrital en educación superior es la llamada a aportar a la Infraestructura de Datos Espaciales del Distrito Capital - IDECA en el ámbito educativo, este es un proceso evolutivo que debe culminar con la inclusión de la totalidad de datos espaciales que permitan la caracterización del sector en la capital, este proceso inicia con el planteamiento actual de la creación del Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional o “NODO” y debe avanzar en la dirección que definen los siguientes lineamientos en su respectivo orden de ejecución o prioridad.
● Definición del grupo de datos fundamentales que alimentan las funciones de la universidad.
● Definición del grupo de datos fundamentales que ofrecerá la universidad a los distintos integrantes de la IDE local (IDECA) y nacional (ICDE).
● Conformación del grupo institucional que lidere el desarrollo de la IDE con la participación de las distintas áreas y dependencias.
● Definición de la política de seguridad de datos espaciales. ● Definición del ciclo de vida de los datos espaciales de la universidad. ● Definición del valor de la información y Utilización de estándares.
• A nivel de metadatos: Normas técnicas colombianas establecidas por el ICONTEC.
• A nivel de geoservicios y geoportales: la normalización a seguir debe estar enmarcada dentro de los estandares OGC (Open Geospatial Consortium), ya que garantizan la interoperabilidad de los servicios y son comúnmente aceptados para compartir datos y recursos informáticos.
69
3.4. DEFINICIÓN DE DATOS FUNDAMENTALES DE LA UNIVERSIDAD
DISTRITAL
3.4.1. Especificación Técnica del Dato Fundamental “Cobertura Educativa”
La Cobertura Educativa se refiere a la capacidad que tiene el Distrito para atender el acceso del servicio educativo en los distintos niveles académicos, en una población objetivo entre los 15 y 30 años de edad. El gobierno distrital necesita evaluar y analizar cómo se comporta la demanda del sector educativo y cómo se debe enfocar los recursos distritales ante esta; dado que la educación es un tema clave y primordial dentro del gobierno distrital, la Universidad Distrital “Francisco José de Caldas”, como el mayor ente educativo distrital propone la Cobertura Educativa como un dato fundamental dentro del IDECA (Infraestructura de Datos Espaciales para el Distrito Capital), el cual será proporcionado por la Universidad Distrital con la colaboración de la Secretaría de Educación del Distrito. La secretaría distrital de educación cuenta con un compendio de estadística, las cuales tiene por objeto la promoción, difusión y uso de datos cuantitativos de los colegios públicos y privados de Bogotá. Como fuentes para recolectar la información, la secretaría utiliza la encuesta escolar (C 600), el sistema de matrícula y el directorio de colegios públicos de Bogotá. De esta manera la información procesada de este dato fundamental cuenta con indicadores, explicados posteriormente, que serán calculados utilizando la información suministrada por la Secretaría Distrital de Educación.
El objetivo del análisis de este dato será el de permitir tomar decisiones y enfocar esfuerzos de cobertura en donde haya déficit de cobertura educativa. Se tendrán en cuenta datos de instituciones educativas oficiales y privadas. Y con estos datos se calcula los diferentes indicadores que pueden apoyar el anáisis de la Cobertura Educativa. Para hacer más fácil el análisis de estos datos en el Distrito, se analizará por localidades. La Universidad Distrital “Francisco José de Caldas” por medio de la Facultad de Ingeniería y específicamente con su grupo de investigación NIDE (Núcleo de Investigación en Datos Espaciales) es el encargado de agrupar esta información y contextualizarla en un aspecto geográfico para compartirlo con el IDECA.
70
3.5. GEOSERVICIOS
3.5.1 Plataforma Tecnológica para los Geoservicios CECAD de la
Universidad Distrital.
Para el caso de la Universidad Distrital F.J.C. se planteó el desarrollo de un modelo de Geoportal para el acceso a la Infraestructura de Datos Espaciales desde el CECAD puesto que este proporciona una infraestructura de Computación de Alto Desempeño, la cual permite la administración de recursos informáticos. Los recursos individuales pueden determinar su capacidad y disponibilidad, y estos pueden ser incluidos dentro de la IDE local y posteriormente dentro de una IDE Nacional. Este laboratorio se aprovechó debido a que tiene proyectos de diferentes grupos de trabajo con especificaciones del Open Geospatial Consortium (OGC); además de tener otros servicios para la clasificación de imágenes usando diferentes algoritmos, entre otros.
Se Implementó ESRI Geoportal puesto que posee aplicaciones para su desarrollo, entre las cuales se encuentra: la capacidad de autenticar y autorizar usuarios, administrar recursos, monitorear y enviar trabajos a recursos remotos, con el fin que los compañeros posean acceso a los recursos distribuidos sobre la red, todo esto utilizando aplicaciones web, a través de un solo punto de acceso, el Geoportal.
Este sistema utiliza como contenedor de servicios ArcGIS Server que funciona en el nodo worker y que incluye GeoServicios para la gestión de recursos, además incluye servicios que realizan tareas específicas como por ejemplo los clasificadores de imágenes, entre otros. En el nodo servidor de credenciales se encuentra MyProxy que desarrolla software para la gestión de clave pública (PKI) con certificados y credenciales de seguridad (certificados y claves privadas).
71
Otro nodo corresponde con el del cliente que utiliza un navegador web con el fin de visualizar las aplicaciones a través del Geoportal. Finalmente el nodo servidor de aplicaciones usa Tomcat como servidor web junto con el framework gridsphere para el despliegue de aplicaciones en el Geoportal y un conjunto de portlets que usan debidamente los GeoServicios que se encuentran en ArcGIS Server.
En el nodo servidor de credenciales se encuentra MyProxy que es el repositorio de credenciales en línea para la grid y funciona de la mano con GSI, ésta aplicación colma la incompatibilidad entre la web y la seguridad grid, permitiendo que a través del Geoportal se usen los recursos de una manera segura.
Este trabajo de investigación examina una alternativa de acceso a la Infraestructura de Datos Espaciales aun poco madura en el país, la cual brinda extensas posibilidades en el desarrollo de nuevas aplicaciones en carácter colaborativo.
Sin embargo, se hace necesario implementar las aplicaciones y servicios básicos del Geoportal para acceder a datos de la Infraestructura de Datos Espaciales. Además de ser sencillo, debe ser seguro y por lo tanto se debe confiar en la transmisión de información y en la autenticación de los usuarios desde el Geoportal de ESRI en el CECAD.
3.5.1.1. Tecnología propuesta de geoservicios. (arcgis for inspire- esri®
geoportal server).
ArcGIS provee una poderosa solución para Infraestructura de Datos Espaciales (SDI - Spatial Data Infrastructures) la cual incluye capacidades, soporte y compatibilidad con INSPIRE, soportando datos, servicios y metadatos los cuales son distribuidos en el framework llamado: ArcGIS for INSPIRE.
72
Figura 26. Arquitectura ArcGIS for INSPIRE
Fuente: ESRI - ArcGIS for INSPIRE
73
ArcGIS for INSPIRE ayuda a las organizaciones a alcanzar la compatibilidad con INSPIRE extendiendo las implementaciones y software ArcGIS existente. ArcGIS for INSPIRE transforma los datos y los conecta a la gran red de INSPIRE. Esta extensión de ArcGIS incluye.
- La extensión para ArcGIS Desktop
- La extensión para ArcGIS for Server
- Compatibilidad con las plantillas de las geodatabases de INSPIRE
- El Servidor Esri® Geoportal Server de código abierto y sus
- Complementos personalizados para catalogar e indexar metadatos compatible INSPIRE
El diagrama muestra el diseño de los principales componentes y los end-points asociados con una implementación de un servidor de Geoportal sobre tecnología ESRI.
74
Figura 27. Arquitectura ArcGIS Geoportal Server
Fuente: ESRI - ArcGIS for PORTAL
75
3.5.2 Arquitectura del Componente de Servicios Web Geográficos
Figura 28. Arquitectura ArcGIS Geoservicios Server
Fuente: ESRI - ArcGIS for PORTAL
76
La implementación en el CECAD de la Universidad Distrital F.J.C. se realizó por medio de tecnología ESRI y específicamente por medio de ArcGIS Server.
ESRI es la principal plataforma para distribuir mapas y capacidades SIG mediante aplicaciones y servicios Web, para mejorar flujos de trabajo internos, comunicar asuntos de gran importancia e implicar a las partes interesadas. El sistema ArcGIS Server permite publicar tareas y servicios geoespaciales; además, proporciona aplicaciones listas para usar y distintas API para poner en marcha su implementación de SIG de servidor. ArcGIS Server se halla disponible para las plataformas Java y Microsoft .NET y ofrece una base muy robusta para arquitecturas de aplicaciones Web y aplicaciones móviles. El diagrama de arquitectura que se muestra arriba (Imagen 4. Arquitectura GeoServicios) ilustra cómo los componentes del software ArcGIS Server se dividen en capas lógicas y físicas.
Con los servicios de ArcGIS, el usuario puede compartir sus recursos SIG en toda la empresa y en la Web. Los recursos SIG son los mapas con contenido de calidad, globos, localizadores, geodatabases y herramientas que administra. Además, el usuario podrá compartir estos recursos publicándolos en ArcGIS Online o ArcGIS Server, donde se exponen mediante interfaces REST, SOAP y OGC.
Con respecto a la Arquitectura de las aplicaciones Web, ESRI proporciona una gran variedad de opciones de arquitecturas de aplicaciones Web, desde las API de JavaScript y los marcos de desarrollo de aplicaciones .NET y Java hasta potentes aplicaciones de Internet basadas en Flex de Adobe o en Microsoft Silverlight o en HTML5.
77
La siguiente es una lista de los Geoservicios que están disponibles con la tecnología de ESRI; sin embargo y como se trata de un experimento computacional, para el trabajo de investigación, solo se implementaron los GeoServicios enumerados como: a, b, c, d y h. Se debe tener en cuenta que, ArcGIS Server proporciona toda la funcionalidad para la implementación de todos estos geoservicios, por tanto, todos estos se podrán implementar en el nodo propuesto, solo es tarea del administrador del sistema de información geográfica habilitar dichos servicios.
3.5.2.1. Características Del Core De Los Geoservicios ESRI.
1. Administrar y almacenar información y servicios geo-espaciales 2. Ejecutar análisis Espaciales complejos. 3. Publicar Servicios web basados en los protocolos REST/SOAP, lo cual
incluye.
a. Mapping Services soporta consultas (WMS opcional) b. Feature Services servicios de edición (WFS y WFS-T para compartir y
actualizar los elementos o Features) c. Image Services para servir imágenes e información ráster (WCS opcional
para publicar imágenes e información ráster) d. Geocode Services para encontrar direcciones e. Geodata Services se emplea para replicación f. Geoprocessing Services soporta publicación y análisis de modelos ad-hoc. g. Search Services para indexar los folders o carpetas y contenidos GIS para
llevar a cabo búsquedas mucho más rápidas. h. Geometry Services para operaciones complejas de geometría (Polygon, Arc,
Pont, etc).
78
3.5.2.2. Estándares OGC Suportados Por Los Geoservicios ESRI.
- OpenGIS Web Map Service (WMS) Implementation Specification 1.3.0
- OpenGIS Web Coverage Service (WCS) Implementation Specification, (Corrigendum) 1.0.0
- Web Mapping Service 1.1.1
- Web Feature Service 1.0.0 implementations
- OpenGIS Filter Encoding Implementation Specification 1.1
- OpenGIS Web Feature Service (WFS) Implementation Specification 1.1.0
- Web Feature Service (Transactional) 1.0.0
- GML 3.1.1 simple features profile 1.0.0,
- OpenGIS Web Coverage Service (WCS) Implementation Specification 1.1.0
- OpenGIS Web Coverage Service (WCS) Implementation Specification Corrigendum 11.1.1
- OGC KML 2.2.0 standard.
En síntesis, ArcGIS Server incluye los siguientes tipos de GeoServicios.
Tabla 1. Tipos de GeoServicios ESRI Portal
79
Para el desarrollo del presente proyecto de investigación, se implementó un prototipo computacional experimental, el cual se logro realizar como servidor web de Georecursos habilitado Cloud en la siguiente dirección o URL.
http://201.245.179.246:8080/arcgis/rest/services/, apoyado en un laboratorio computacional, el cual sirve de punto de partida para la creación de un Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (nodo) dentro de una Infraestructura de Datos Espaciales local. La consola de administración, cuyo acceso ha sido restringido por seguridad de la información, para la aplicación y la administración de los Georecursos, tiene la siguiente dirección o URL: http://201.245.179.246:8080/arcgis/manager.
3.5.3 Descripción del Servicio Web Geográfico.
Existen múltiples definiciones acerca de los Servicios Web, sin embargo y de acuerdo con el World Wide Web Consortium (W3C: comunidad internacional que desarrolla estándares que aseguran el crecimiento de la Web a largo plazo), los Servicios Web se definen de la siguiente manera: Los Servicios Web (Web Services), son “un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web.
Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web”. De acuerdo con el World Wide Web Consortium (W3C) los Servicios Web sirven o son usados por que “proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones web, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones web y, que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.”
80
Figura 29. Funcionamiento Servicios web
Fuente: http://www.w3c.es/Divulgacion/GuiasBreves/ServiciosWeb
3.5.4 El CECAD, como nodo ofrecera los siguientes formatos de
GeoServicios.
Web Map Service (WMS)
Es un Servicio Web que ofrece una interface estándar para Servicios Web de Mapas (Web Map Service - WMS) del Open Geospatial Consortium (OGC) para Sistemas de Información Geográfica abiertos (OpenGIS); este estándar provee una simple interface HTTP para que los usuarios puedan solicitar la imagen de un mapa Geo-Registrado desde una o más Bases de Datos GeoEspaciales Distribuidas.
A través del protocolo WMS se sirven imágenes de forma segura y rápida. Los datos permanecen seguros, ya que se sirven como imágenes renderizadas. A menos que se digitalice encima de las imágenes, no hay forma de copiar los datos originales de las imágenes de los mapas. La apariencia de cada capa de mapa se puede controlar utilizando el estándar SLD que permite definir el color y etiquetado de los features, o geometrías, de las diferentes capas.
81
La combinación de estas reglas con la posibilidad de filtrar estilos dependientes del nivel de escala (filtros OGC), permite ir añadiendo cada más detalle en la visualización de los mapas, a medida que se acerca el zoom a un zona. También es capaz de gestionar amalgamiento de etiquetas, agrupaciones y prioridades de dibujado. Permite enviar datos puramente vectoriales a clientes que implementen el protocolo WFS. Un cliente WFS es capaz de descargar datos vectoriales, que luego pueda utilizar en sus mapas, análisis espaciales y otras operaciones. También, si el usuario tiene autorización, puede enviar de vuelta los datos modificados al servidor, para almacenar en el mismo los datos modificados, utilizando el protocolo WFS-T. Los datos se pueden transmitir utilizando GML (comprimido), así como otros estándares de formatos de datos como shapefile y json. Se pueden enviar datos ráster a un cliente utilizando protocolo WCS. Un cliente GIS puede pedir datos ráster para utilizarlos en análisis espaciales. Esto permite la creación de aplicaciones que pueden modelar el proceso descrito por tus datos.
Re-proyección ‘al vuelo’: ArcGIS Server soporta la mayoría de Bases de Datos de proyecciones EPSG y puede re-proyectar a cualquiera de ellas bajo petición, lo que permite a las aplicaciones clientes delegar la carga de procesamiento de re-proyecciones al servidor.
WMS Tiling Cache
GeoWebCache es un cliente de tiles WMS. Corre un servidor proxy entre el cliente de mapa y el Servidor de Mapas, “cacheando” los tiles, a medida que se piden, y consiguiendo una mejora considerable en el tiempo de proceso para la generación de imágenes. GeoWebCache se ha integrado dentro de ArcGIS Server.
Web Coverage Service (WCS)
Es un Servicio Web que ofrece una interface estándar para Servicios Web de Coberturas (Web Coverage Service - WCS) del Open Geospatial Consortium (OGC) para Sistemas de Información Geográfica abiertos (OpenGIS); este estándar provee una simple interface y operaciones que posibilitan la interoperabilidad en el acceso a Coberturas GeoEspaciales
[http://www.opengeospatial.org/ogc/glossary/c].
82
Web Feature Service (WFS)
Es un Servicio Web que ofrece una interface estándar para Servicios Web de Coberturas (Web Feature Service - WFS) del Open Geospatial Consortium (OGC) para Sistemas de Información Geográfica abiertos (OpenGIS); este estándar permite interactuar con los mapas servidos por el estándar WMS, como por ejemplo, editar la imagen que nos ofrece el servicio WMS o analizar la imagen siguiendo criterios geográficos.
3.6. GEOPORTALES
Un geoportal tiene por objetivo, ofrecer al usuario de manera práctica e integrada, el acceso a una serie de recursos, geográficos y no geográficos. De esta forma, en el marco de una Infraestructura de Datos Espaciales - IDE, los geoportales resuelven la conexión física y funcional entre los grandes repositorios de datos y los usuarios.
Los visitantes del geoportal podrán descubrir y acceder a los recursos publicados en el catálogo, y eventualmente utilizarlos en sus proyectos o tareas particulares. Algunos usuarios pueden incluso obtener autorización para publicar ellos mismos los metadatos de sus recursos SIG en el geoportal.
La interfaz del geoportal está pensada principalmente para soportar la funcionalidad de descubrimiento (o búsqueda) de metadatos. De esta forma el Geoportal del Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (Nodo) de la Universidad Distrital será el único punto de acceso, el cual brindará las opciones de consulta, descubrimiento y publicación de datos geográficos y alfanuméricos relacionados con los procesos misionales de la Universidad Distrital.
83
3.6.1. Plataforma Tecnológica para el Geoportal y el Visor de Información
Geográfica
Los componentes de software y hardware que intervienen en los procesos de gestión y descubrimiento de la información en una IDE, están estrechamente ligados a los metadatos, los cuales desde el punto de vista técnico, están enmarcados en los lineamientos del sistema. Desde este punto de vista el geoportal brinda acceso a los recursos, por medio de los metadatos, y adicionalmente permite la disposición on-line de algunos recursos, por medio de servicios de información geográfica, desplegados a través de un geovisor.
Figura 30. Concepto de Geoportal
Fuente: ESRI
Desde el punto de vista del software comercial, se encuentra ESRI con el Portal for ArcGIS. Esta solución provee un ambiente para compartir y distribuir recursos geográficos en una organización. Esta solución permite entre otras.
84
● Publicar mapas, aplicaciones y herramientas para cualquiera en una organización
● Compartir Mapas web, servicios de mapas, servicios de imágenes, y servicios de geoprocesamiento
● Búsqueda y descubrimiento de mapas, aplicaciones web, gallerías para dispositivos móviles.
● Es altamente personalizable ● Integración con visores de mapas y herramientas para la elaboración de los
mismos.
Figura 31. Adaptación portal de www.arcgis.com (ArcGIS Online)
Fuente: Elaboración propia a partir de ESRI For PORTAL
85
Una de las grandes ventajas es el ambiente colaborativo soportado en la plataforma, en donde los usuarios pueden tener un espacio para crear sus propios mapas, usando como fuentes los servicios propios de la UD, así como los servicios de otras instituciones y sus propios datos. Este tipo de estrategias colaborativas donde los usuarios pueden publicar desde mapas hasta complejos servicios de procesamiento o aplicaciones web, incentiva el uso de la información geográfica y puede ser usado como una ventana para que las personas publiquen sus estudios y resultados de sus investigaciones y potencializar este aspecto en la UD.
Al ser de ESRI, cuenta con una perfecta integración con la gama completa de productos de esta casa de software GIS, como ArcGIS Server y sus extensiones, y el catálogo de metadatos con Geoportal Server. La UD en la actualidad cuenta con licenciamiento de algunos productos de ESRI, con lo cual es muy conveniente implementar alguno de estos dos productos. El Geoportal Server se tratara en la sección de Nodos de Metadatos. Vale la pena mencionar que se debe vincular el punto de búsqueda de ambas plataformas, para que se pueda cumplir con la premisa de que solo haya un punto de ingreso al nodo.
Desde el lado de los geovisores, nuevamente ESRI ofrece una gran variedad de API´s para el desarrollo de estas aplicaciones. Ofrece las plantillas listas para usar y el código fuente para realizar las personalizaciones. La solución Portal for ArcGIS cuenta con visores integrados en Silverlight, Javascript y HTML5, completamente personalizables. Sin embargo también existe el de Flex, el cual es el recomendado, debido a las tendencias de desarrollo tanto de ESRI como de Adobe de en un futuro, migrarse a HTML5.
Para implementar este tipo de soluciones, desde el punto de vista estratégico debe haber una política institucional en donde se reglamente y estandarice el uso de esta plataforma, así como sus reglas de negocio, interacción con otros sistemas (Geoportal Extension desde lo geográfico, y demás sistemas institucionales para garantizar aspectos como seguridad de los usuarios, etc). Desde el punto de vista técnico debe haber un acompañamiento de expertos, como los estudiantes de maestría, bien sea desde los proveedores o personal altamente capacitado en el soporte de este tipo de plataformas.
86
3.7. NODOS
La Universidad Distrital contara con una colección de tecnologías, políticas y arreglos institucionales que abrirá la posibilidad de disponer y compartir datos espaciales de ser implementados los diseños y arquitectura previos (Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional). Este conjunto de elementos arquitectónicos serán integrados en términos lógicos en el Geoportal, de esta forma se proveerá una base para el descubrimiento, evaluación y acceso a datos espaciales a los usuarios, proveedores y organizaciones internas o externas. Entre las múltiples ventajas que representará la implementación del Geoportal se encuentra la búsqueda conjunta del Portal y el Nodo de Metadatos, la tecnología Esri permite dicha integración para disponer una única puerta de acceso al portal y al nodo, otra ventaja está relacionada con la posibilidad de compartir e integrar las funcionalidades de publicación, descubrimiento y representación de datos espaciales asociados al nodo de la Universidad. En la siguiente figura se observa un esquema lógico del funcionamiento del Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (nodo) y sus componentes, el nodo CECAD de la Universidad Distrital contara con un esquema Similar. Aquí la interfaz de usuario estaría disponible mediante Portal for ArcGIS, expuesto en la sección anterior, y este integrado con Geoportal Server el cual se expone más adelante en este capítulo.
Figura 32. Componentes del nodo IDE Universidad Distrital
Fuente: Elaboración propia a partir de Doug Nebert
87
3.7.1. Plataforma tecnológica para la Gestión de Metadatos
Como soporte a los elementos arquitectónicos lo que se traduce en el Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional definidos previamente y con el ánimo de apoyar y armonizar los elementos que hacen parte del nodo CECAD, el componente de software que soportará la integración y gestión del nodo es ESRI Geoportal Server, además de apoyar la administración del portal y el sitio web, permite el registro de los recursos geoespaciales de otros proveedores y consumidores sin duplicar recursos, simplemente almacenando los catálogos de metadatos e información necesaria para acceder a dichos recursos. ESRI Geoportal Server es un producto libre y de código abierto, que posibilita el descubrimiento y uso de recursos geo-espaciales incluyendo DataSets (información vector), información ráster y servicios web. En otras palabras, el Servidor de Geoportal de ESRI, es un sitio web funcionalmente completo porque está compuesto de varias aplicaciones que permiten la Publicación, el descubrimiento y uso de documentos de metadatos basados en estándares OGC que describen los servicios y la información geográfica.
Figura 33. Catálogo de Metadatos – Geoportal Server
Fuente: Universidad Distrital F.J.C.
88
El catálogo de metadatos de ESRI Geportal Server inspecciona los metadatos de los recursos registrados en el servicio de catálogos bajo el estándar CS-W 2.0.2 del Open Geospatial Consortium, con esto se garantiza una integración general con otros nodos de interés, su publicación y acceso mediante el uso de herramientas estandarizadas; con estas capacidades se genera un gran beneficio para los usuarios o integrantes del nodo, al igual que para los demás interesados en disponer o usar los recursos de información geográfica registrados en el nodo.
Como se ha descrito previamente la creación del Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (Nodo) CECAD de la Universidad Distrital brindará la posibilidad de publicar y poner a disposición de los usuarios en general el acceso a recursos geoespaciales, no solo aquellos que son producidos por la Universidad, sino los demás recursos relacionados que hayan sido registrados en el gestor de metadatos. Con Esri Geoportal Server los productores de datos registrados pueden publicar sus recursos en el servicio de catálogo de la Universidad Distrital, estos recursos pueden ser capas (layers), herramientas de análisis, servicios web, entre otros, de este modo los productores cuentan con herramientas web sencillas que les permite crear y cargar metadatos existentes o permitir la generación automática de los mismos.
Existen dos grandes herramientas que complementan el desarrollo del nodo IDE, la primera de ellas se relaciona con el soporte a la creación de perfiles de metadatos, estos perfiles facilitarán la creación de grandes volúmenes de metadatos por parte de los productores; la segunda herramienta se relaciona con el descubrimiento de datos en la que los usuarios por medio de una interfaz web pueden acceder a los recursos que componen el modo de acuerdo a sus preferencias personales, haciendo uso de búsquedas simples, federadas, pre-visualización, acceso, descarga e integración con herramientas de escritorio.
Con el fin de aprovechar la totalidad de los beneficios mencionados previamente la Universidad debe plantear y asumir el esquema institucional de responsabilidades y roles, de esta forma el nodo contará con los responsables necesarios en los diversos aspectos y garantizará el correcto funcionamiento del nodo.
89
3.7.2. Lineamientos para la creación del nodo de la Universidad Distrital
La creación del Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (nodo) IDE CECAD para la Universidad Distrital es un gran reto para esta institución ya que será un paso hacia la total participación como integrante de las Infraestructuras de datos espaciales del Distrito Capital (IDECA) y la Colombiana (ICDE), en este sentido la responsabilidad por su diseño, implementación y operación es mayúscula dado que se debe integrar armónicamente con los actores de la infraestructura y a su vez implementar los estándares necesarios para que esta integración sea lo más simple posible.
El Modelo de Accesibilidad a Servicios de Información Geográfica en la Nube Computacional (nodo) IDE CECAD de la Universidad Distrital es la oportunidad para hacer visible y consolidar los avances institucionales, su diseño e implementación deben ser consistentes con los planes y necesidades institucionales, de esta forma será posible el uso de este canal de comunicación con el mundo para integrar a la Universidad Distrital con las demás instituciones del sector educativo, así como los sectores asociados y empresas del estado Colombiano.
Las actividades encaminadas a lograr este objetivo deben orientarse a.
1. Identificación y priorización de entidades (EAB, IDECA, DANE, entre otras) para realizar la integración en primer nivel. (Acceso a datos y servicios)
2. Definición de los canales de comunicación con las entidades 3. Adopción de estándares del orden nacional y distrital para el manejo de la
información relacionada con la educación 4. Definición de roles, niveles de acceso y confidencialidad de la información. 5. Integración con los sistemas institucionales. 6. Identificación de servicios a la ciudadanía basados en la información
geográfica y alfanumérica producida por la universidad.
90
4. MODELO PROPUESTO
4.1. INTRODUCCION
El trabajo de investigación propone una arquitectura Cloudlet, entendiéndose el concepto Cloudlet como una pequeña Cloud localizada geográficamente cerca a los usuarios de tecnología móvil. Ésta debe estar instalada en servidores que hospeden una o varias máquinas virtuales (VMs) en donde los dispositivos móviles puedan descargar (offload) el consumo computacional intensivo; sin embargo, la Cloudlet debe poder ser descubierta, localizada y debe carecer de estado. Cloudlet es un grupo de computadores confiables, ricos en recursos computacionales, conectados a internet y, disponibles para el uso por los dispositivos móviles que se encuentren cercanos a dicha Cloudlet. [2] El modelo propuesto en el presente trabajo de investigación, es una adaptación del concepto Cloudlet; es una arquitectura que puede ser vista como una arquitectura de alto nivel con el fin de permitir la descarga de código de las aplicaciones en un ambiente hostil. Cloudlet es la capa intermedia en una arquitectura de tres capas, es decir, es la capa entre la infraestructura Cloud y los dispositivos móviles [4]
Figura 34. Arquitectura en tres capas: Dispositivo Móvil, Cloudlet y Núcleo Central (Cloud)
Fuente: [4]
91
Como se ha expuesto en este trabajo de investigación, tanto los Frameworks, las aplicaciones y las herramientas existentes para llevar a cabo el geo-procesamiento y el análisis de grandes volúmenes de información espacial (Big Spatial Data) son extremadamente complejas. Con el objetivo de analizar los retos de diseño para estas arquitecturas complejas, se diseñó y adopto un modelo computacional experimental y teórico con el fin de posibilitar Servicios Web de Mapas (Web Mapping Services-WMS) en una nube computacional con tecnología móvil (Mobile Cloud Computing).
Aunque existen proveedores altamente acoplados como Amazon, IBM, Rackspace, Google, Microsoft, CSC, BlueLock, NephoScale, Verizon/Terremark, Joyent, (estos son los diez mejores proveedores de Cloud Compuitng a nivel mundial) estas tecnologías solo funcionan bien entre sus propios componentes y en sus propias arquitecturas.
Del planteamiento del problema de investigación, subyace la necesidad de saber elegir entre un dispositivo móvil liviano o un dispositivo móvil robusto; esto hoy por hoy es un inconveniente por que el número de dispositivos móviles con alto poder de procesamiento aún es muy bajo.
Se espera que, las aplicaciones en el futuro cercano, utilicen un balanceador que, determine lo que se pueda procesar localmente en el dispositivo móvil en tiempo real, que el balanceador determine que parte de la aplicación se deba descargar en la Nube (Cloud) por medio de un operador móvil de internet y, que determine que parte de la aplicación pueda ser descargada en una arquitectura Cloudlet vía conexión Wi-Fi. [2]
92
4.1.1. Trabajo Relacionado
La computación penetrante (embebida), como lo es el procesamiento en los dispositivos móviles, requiere la habilidad de descubrir recursos computacionales disponibles localmente, en otras palabras, las aplicaciones requieren un servicio de descubrimiento basado en la localización de tal manera que, cuando se provea la localización de un usuario o de un dispositivo móvil, este pueda “buscar” por cercanía digital recursos computacionales. [5] Los acercamientos existentes para el descubrimiento de recursos que dependen de la localización, están clasificados en su gran mayoría dentro de dos categorías:
a. Métodos centralizados, los cuales se apoyan en un simple índice para resolver las consultas espaciales. Los Sistemas de Información Geográfico (SIG o GIS de sus siglas en inglés) han emergido en unas pocas décadas gracias a los avances en los Sistemas de Administración de Base de Datos (DBMS) y gracias a los Sistemas de rastreo y posicionamiento como por ejemplo los GPS., llegando a ser en la actualidad un estándar de la industria a nivel mundial. [7] Las aplicaciones de los Sistemas de Información Geográfico (GIS) existen gracias a los modernos DBMS y a gracias a la capacidad que esta tecnología ofrece para la implementación de servicios basados en la localización (location-based services-LBS). Los LBS integran la localización de los dispositivos móviles con otra información espacial, es decir, son espacialmente dependientes. [12] Google
Latitude, Foursquare, Facebook Places, y Follow Me, son ejemplos basados en Cloud de implementación de servicios basados en la localización (Location-based services-LBS), lo cual permite que los usuarios compartan su localización con sus amigos u otras personas. El caso de The NearMe wireless proximity server, comprara las huellas de los dedos de las manos de los clientes Wi-Fi con objeto de procesar computacionalmente su posible cercanía. [13] MoCA (Mobile Collaboration Architecture) es una capa intermedia cliente-servidor, para el desarrollo y despliegue de aplicaciones con sentido de contexto, es decir, MoCA soporta la movilidad monitoreando la localización de un cliente móvil y hacer luego el cambio a una aplicación proxy.
93
El caso Hydra [15], facilita el desarrollo de aplicaciones penetrantes (embebidas) proveyendo agentes móviles que siguen al usuario en un ambiente igualmente invasivo o penetrante, construyendo una máquina virtual la cual se ajusta a las necesidades del usuario actual basado en su localización, las tareas que requiere ejecutar, en el número de personas cerca, entre otros. Este acercamiento utiliza un simple punto de búsqueda para almacenar la localización de los integrantes, de esta forma resuelve las consultas para los recursos basados en la localización. Se implementa en la capa del par, mas no en la capa global de la arquitectura.
b. Métodos distribuidos, estos pueden ser descompuestos además en, dependientes de infraestructura y no dependientes de ella. El descubrimiento de manera eficiente de la “cercanía” de pares es un área de interés en las aplicaciones peer-to-peer (P2P); en donde los nodos interactúan directamente con otros nodos de manera localizada y descentralizada. [17]. Zero Configuration
Networking (zeroconf) y las extensiones de servidor de mensajería del protocolo de mensajería y presencia (XMPP), ambas posibilitan el descubrimiento automático de servicios disponibles en una red de área local (LAN). Virtual Cloud, emplea mensajes XMPP con el fin de facilitar la formación de Clouds móviles por demanda, compuesta por dispositivos móviles que se encuentren próximos entre sí. [18] El descubrimiento de los pares próximos, puede ser implementado en la parte superior de una infraestructura descentralizada de ruteo y localización. [27] Sin embargo, los acercamientos basados en tablas de ruteo y de superposición requiere conocer al menos un par listo en la red, el cual actuara como punto de entrada para un nuevo par. Los acercamientos netamente ad hoc se ubican de manera inherente tanto en el espacio como en el tiempo, debido a la atenuación de las señales de radio a medida que estas se propagan. Una tecnología de telecomunicaciones que posibilita rangos largos para el descubrimiento P2P es FlashLinQ; este permite aproximadamente 3218,688 Mts y opera en el espectro de los 5 MHz. [75] En un punto del modelo, se empleara distancias cortas de comunicación para localizar y co-localizar usuarios de tecnología móvil. Virtual
Compass construye una gráfica en dos dimensiones con la cercanía de los dispositivos midiendo las señales fuerte de manera periódica ya sean Wi-Fi o
Bluetooth. [77] El paradigma Mobile Cloud Computing integra el concepto Cloud Computing dentro de los ambientes de tecnología móvil, superando de esta forma obstáculos de desempeño en ambientes heterogéneos y escalables, obstáculos como: vida de la batería, retrasos en la comunicación, poco almacenamiento y, el ancho de banda, entre otros. [78]
94
Figura 35. Vista general Mobile Cloud Computing
Fuente: [78]
La figura muestra de manera general, la arquitectura que permite a los dispositivos móviles descargar tareas en una ubicación remota y, convertirse posteriormente en clientes del proveedor de servicios mientras estén conectados por medio de una conexión inalámbrica. A través de muchos años, diferentes tipos de arquitecturas han sido propuestas por varios grupos de investigación, con el fin de llevar los servicios Cloud a los dispositivos móviles.
4.1.2. Principios
La definición oficial de Mobile Cloud Computing, la precisa [78] de la siguiente manera: “Mobile Cloud Computing at its simplest, refers to an infrastructure where
both the data storage and the data processing happen outside of the mobile
device. Mobile cloud applications move the computing power and data storage
away from mobile phones and into the cloud, bringing applications and mobile
computing to not just smartphone users but a much broader range of mobile
subscribers". Actualmente, Cloud Computing enfrenta retos como cualquier otro modelo de comunicación, tal es el caso que, diferentes arquitecturas de Mobile
Cloud Computing presentan diferentes preocupaciones de diseño lo cual ocasiona diferentes retos para los investigadores; sin embargo, existen algunos problemas relevantes para casi todos los tipos de Mobile Cloud Computing.
95
Figura 36. Arquitectura general Mobile Cloud Computing.
Fuente: [79]
96
4.1.3.1 Seguridad y Acceso a los Datos
En el paradigma Cloud, existen un grupo de problemas importante de políticas de seguridad, lo cual incluye algunos requerimientos NO-Funcionales como la fiabilidad, la privacidad, la responsabilidad y, la seguridad. [80]
4.1.3.1.1 Integridad:
Con el objeto de garantizar la integridad que proteja a los datos con el fin que no puedan ser modificados por terceros, esta se basa en dos principios fundamentales: un principio es prevenir la modificación de la información por usuarios no autorizados y la el otro principio es, la modificación no autorizada de los datos por usuarios no autorizados. [80]
4.1.3.1.2 Autenticación:
Proceso de identificar y validar a los usuarios por medio de una contraseña y nombre validos proveyendo el derecho para acceder a los servicios o a cualquier otro recurso de la Cloud. [80]
4.1.3.1.3 Confidencialidad:
Es garantizar que la información proporcionada no se ha tomado de una persona no autorizada. Es decir, cuando se trata tanto de información almacenada como los datos que viajan vía internet. [80]
En el presente trabajo de investigación, no se profundiza en el modelo de seguridad, existen diversos modelos que se pueden adoptar, los cuales implementan altos estándares de seguridad como algoritmos de encriptación, algoritmos de validación de usuario, entre otros.
4.1.3.2 Gestión de los Recursos Cloud
La administración de los recursos presenta sus propios problemas, los cuales son inherentes con el paradigma Cloud Computing porque en la teoría, los recursos basados en servicios de la Cloud Computing no son diferentes de los problemas en la gestión de los recursos dentro de un ambiente propio, la única diferencia es, que la gestión de los recursos en la Cloud es remota. [81]
97
De acuerdo con [82] existen actualmente tres tipos de modelo Cloud Mobile:
4.1.3.3 Mobile Client Cloud Computing (MCCC)
En este modelo los dispositivos móviles se comportan como clientes y el usuario móvil accede a los servicios que están siendo proveídos por la Cloud por medio de una capa ligera con una interface web. La Cloud se carga de servicios durante el tiempo que el cliente se encuentre conectado. [82]
4.1.3.4 Mobile Server Cloud Computing (MSCC)
En el modelo Cloud/Cliente el concepto de particionalmente de tareas, surge cuando los usuarios móviles liberan una parte de las tareas para que estas sean procesadas en la Cloud.
4.1.3.5 Modelo Cloud
En este modelo, los dispositivos móviles son parte esencial de la Cloud; es decir, uno o más dispositivos móviles, crean la estructura de la Cloud Computing.
4.1.3.6 Servicios RESTful (REpresentational State Transfer)
Los servicios de descubrimiento basados en la localización, crean Cloudlets los cuales son los responsables de mantener el conocimiento de los recursos digitales disponibles dentro de un espacio específico en una región determinada. Una arquitectura RESTful es candidata ideal para cualquier tipo de servicio web basado en Cloudlet. Esta arquitectura es ideal porque REST define un completo grupo de principios de arquitectura por lo cual se ha convertido en una técnica de diseño estandarizada, siendo la base para muchos de los servicios en la Web 2.0, como por ejemplo aquellos proveídos por Twitter, Amazon, Google y Facebook, entre otros. REST es una técnica de diseño para la implementación de llamados a procedimientos remotos sobre la web. En las arquitecturas REST, los clientes solicitan servicios a los servidores, los cuales procesan las peticiones retornando la respuesta a los clientes (Patrón de iteración cliente-servicio: Request/Response). [83]
98
Por otra parte, según se ha citado, REST integra la funcionalidad en el nivel de la aplicación directamente con el Hypertext Transfer Protocol (HTTP), lo cual no requiere construir un nivel superior o una capa intermedia. La cualidad REST de ser ligero por naturaleza, lo hace ideal para los recursos de computación penetrante o embebida en los dispositivos móviles con recursos limitados. [83] Para el modelo en el presente trabajo de investigación, el servicio de descubrimiento por proximidad, la noción del escenario de dispositivos móviles por cercanía se traducirá al concepto REST de exposición de recursos.
4.2. JUSTIFICACIÓN DEL MODELO
Nuestro modelo para la implementación de un servicio de descubrimiento basado en la localización, crea Cloudlets las cuales son las responsables de mantener el conocimiento acerca de los recursos digitales disponibles en una región especifica en nuestro entorno.
Cloudlet es un recurso de computación confiable con una excelente conectividad a internet, conectividad que está disponible para ser empleada por los dispositivos móviles físicamente cercanos conectados a una red LAN inalámbrica. [72] Nuestro acercamiento basado en Cloudlets, es con el objetivo de descubrir pares co-localizados; el modelo presenta una ventaja significativa incluso para aplicaciones que funcionan en espacios con varios miles de dispositivos en una área pequeña (por ejemplo, una universidad, entre otros).
En el presente trabajo de investigación, el uso de una infraestructura Cloudlet, refuerza y facilita la interacción Par a Par (P2P) entre los dispositivos que están físicamente cercanos unos a otros. La proximidad física de los pares, no es un requerimiento para nuestro modelo de investigación, sin embargo, es de mucha ventaja si la superposición P2P existe para almacenar los eventos espacio-temporales. [84]
Problemas relacionados con la asignación y la liberación de recursos virtuales dentro de una arquitectura física disponible como respuesta al inicio, pausa, resumen y terminación de las instancias de recursos virtuales, es una de las mayores preocupaciones para los investigadores de la Cloud Computing. [84]
99
4.3. RETOS ACTUALES
La problemática en la infraestructura a la que hace referencia el presente trabajo de investigación, es la movilidad y la tolerancia a fallos; de igual manera, otro problema es la interoperabilidad, la privacidad, la seguridad y, el conocimiento del contexto. [47]
4.4. RECURSOS
Los requerimientos mínimos que se requiere o que se sugiere, con el fin de configurar e implementar un servidor Cloud Computing son: la memoria física, el consumo de energía y el almacenamiento. [2]
Memoria Física: la mayoría de los dispositivos móviles, no tiene la capacidad de ejecutar en memoria aplicaciones que demanden consumo computacional intensivo; por tal motivo, cuando se configure la Cloudlet, se debe atender las necesidades de memoria de los nodos que integraran la Cloudlet. Consumo de Energía: este ítem es el más restrictivo para los dispositivos móviles puesto que la batería en los dispositivos no se puede reponer a menos que esta se insertada de manera manual.
El Almacenamiento: el almacenamiento de los datos en cualquier aplicación es indispensable, por extensión, el almacenamiento en la Cloud es también indispensable.
La Ubicación este ítem es relevante por dos aspectos: el primer aspecto se debe a que el recurso del nodo está muy cerca al centro topológicamente hablando, por consiguiente, el costo en la comunicación es mucho más bajo; el segundo ítem relevante es cuando el nodo se mueve fuera del rango de alcance de la red, el tiempo que se tarda en encontrar el borde es mayor, lo que se traduce en más tiempo para transferir la información.
100
La carga: para entender la capacidad de respuesta los recursos de los nodos se debe considerar la carga interna de los dispositivos móviles. En futuras investigaciones, se ampliara la manera de administrar la carga en los recursos de los nodos.
4.5. HERRAMIENTAS, MATERIALES Y MÉTODOS
Como el modelo experimental computacional se implementó temiendo en cuenta alguna parte de código abierto y, parte de las herramientas empleadas se descargaron de internet y fueron instaladas en el ambiente experimental, Tanto los manuales técnicos y de instalación que se emplearon para la configuración del ambiente Mobile Cloud, es la que viene por defecto con estas herramientas.
En la comunicación móvil, se han desarrollado aun pocas herramientas con el fin de soportar este concepto, sin embargo, existen herramientas que se emplean para el desarrollo de modelo prototipo como las herramientas de desarrollo de software Java para Android (Android SDK). Power Tutor Tool1 es empleada para medir el consumo de la batería. AlfredO es la herramienta empleada para el despliegue, este modelo se adoptó puesto que soporta la distribución física de la aplicación entre el cliente (dispositivo móvil) y el servidor.
4.5.1.Weblets: las aplicaciones generalmente están compuestas por un grupo de funcionalidades independientes que comunican a un grupo de unidades llamadas Weblets. En [86] se introdujo el concepto de Weblet, es una sub-división de un sistema que posee características significantes de portabilidad.
1 Powertutor website. Disponible: http://powertutor.org/. Accedida 03 Agosto 2014.
101
Este marco (Framework) soporta el concepto de aplicaciones elásticas con el fin de ser empleadas en los dispositivos móviles. Para el ahorro de energía, se adoptó el concepto de particionalmente para ahorro de energía de Microsoft, concepto de infraestructura empleando asistencia para dispositivos móviles Microsofts MAUI (Mobile Assistance Using Infrastructure), [4]
Este concepto posibilita una granularidad fina particionando el código hacia la virtualización. Este concepto logra seleccionar un servidor remoto o local para la descarga de la aplicación en tiempo de ejecución aunque la aplicación se deba o no descargar.
Figura 37. Arquitectura MAUI.
Fuente: [4]
102
4.5.2. CloneCloud:
Es una herramienta basada en la presentación, construida y basada en el concepto de partición de aplicaciones hacia servidores remotos en la Cloud y migración dinámica de VMs (Virtual Machines). Esencialmente esta arquitectura abarca la idea de descarga de tareas hacia un servidor cercano, el aporte de este modelo reside en que las tareas son ejecutadas en una imagen de todo el sistema clonado del dispositivo móvil. [87]
Figura 38. Flujo de control cliente sustituto.
Fuente: [88]
103
4.5.3. Cloudlets Basados en VM (Virtual Machines): La definición de Cloudlets y el concepto de las Cloudlets basadas en VM fue introducido por Satyanarayanan [72]; los Cloudlets son computadores enriquecidos en recursos y computadores en cluster.
De la misma forma en que los Cloudlets comparten la misma red LAN inalámbrica con los dispositivos móviles, de igual manera, los usuarios de tecnología móvil aprovechan la tecnología de máquinas virtuales para instanciar de manera veloz servicios de software personalizados en un Cloudlet cercano.
Figura 39. Arquitectura Sistema CloneCloud.
Fuente: [89]
104
El aporte de este trabajo es, los autores identifican la personalización veloz de infraestructura para distintas aplicaciones como un requerimiento critico de esta arquitectura; los autores evidencian un prototipo como prueba de concepto y sugieren que este requerimiento en efecto se mapea con la tecnología de VMs.
Antes que las tareas sean descargadas a la Cloudlet, el dispositivo móvil transmite primero una pequeña VM que se superpone a la Cloudlet; esta se predice que, posee la mayoría de VMs base a partir de las cuales se derivó la VM que se superpuso a la Cloudlet. A esto se le denomina, síntesis dinámica de VMS. [72]
Figura 40. Síntesis Dinámica de VM.
Fuente: [72]
105
Sobre la base de las consideraciones anteriores, en las comunicaciones móviles, los dispositivos pueden ser configurados para recibir y soportar agentes móviles y así ejecutar diversas tareas de procesamiento. El paradigma de los sistemas multi-agentes (Multi-agent Systems - MAS) será implementado como herramienta con el fin de administrar la Cloudlet. Las Cloudlets ricas en Georecursos es la estrategia en Mobile Cloud Computing (MCC) que reduce la latencia a un hop (en redes, un hop representa una porción de la trayectoria entre el origen y el destino) y la demanda por el ancho de banda de los usuarios móviles. [79]
Según se ha visto en el presente trabajo de investigación, Mobile Cloud Computing (MCC) se define como la combinación de la web móvil y el paradigma Cloud Computing. Lo que constituye la herramienta más popular para que los usuarios móviles accedan a las aplicaciones y servicios en internet. [90]
Tabla 2. Porque las Cloudlets son más apropiadas.
Fuente: [90]
Un agente móvil (Mobile Agent - MA) está compuesto por la descripción de un programa y datos móviles, mientras que cada nodo en la red provee nombres de servicios y datos locales.
106
Así mismo, en la revisión del estado del arte el modelo básico de agentes se define como: “Una entidad computacional, la cual actúa en favor de otros, es
autónomo, proactivo y reactivo, exhibe la capacidad de aprender, coopera y tiene
movimiento”. [91]
Figura 41. Ciclo de vida Agente Móvil
Fuente: [90]
4.5.4. Estándares del Open GeoSPatial Consortium (OGC):
Muchos de los estándares OGC desarrollados en los últimos años son estándares para entornos de servicios web y, estos estándares son referidos colectivamente como OGC Web Services (OWS) (Ver Anexo A) La figura inferior proporciona un esquema general de arquitectura para los OGC Web Services. Este esquema identifica las clases genéricas de servicios que participan en diversas actividades de geoprocesamiento y localización. http://live.osgeo.org/es/standards/standards.html.
107
Figura 42. Marco de referencia estándares servicios web para Geoprocesamiento
Fuente: http://live.osgeo.org/es/standards/standards.html
4.5.5. Herramientas Adicionales de Software:
Un recurso es un objeto que una aplicación cualquiera puede asociar con una localización geográfica, por ejemplo, el dispositivo móvil de un usuario, el sensor embebido en el medio ambiente, un mensaje que depende de su localización o, cualquier agente de software móvil que se desplaza entre maquinas. El motor de Base de Datos Oracle, implementa el concepto ST_GEOMETRY o almacenamiento binario de geometrías, al mismo tiempo, la Base de datos geográfica (Geodatabase) 2 implementa R-Tree para la indexación inteligente y la consulta eficiente de datos espaciales. [91]
2 www.ESRI.com
108
El API para los servicios REST esta implementado por medio de Node.js3 Node.js es una plataforma construida sobre Chrome's JavaScript runtime, con el objetivo de construir de manera rápida y fácilmente aplicaciones de red escalables. Node.js emplea un modelo orientado a eventos, sin bloqueos de I/O que lo hace ligero y eficiente, perfecto para aplicaciones que requieren consumo intensivo de datos en tiempo real, aplicaciones que se ejecutan a través de dispositivos móviles distribuidos. Finalmente, el sistema de agentes ha sido desarrollado con el software Java Mobile Edition y desarrollado sobre dispositivos móviles con sistema operativo Android. [91]
4.6. CAPA INTERMEDIA
Una arquitectura de capa intermedia puede ser aprovechada para alcanzar los objetivos y además, para poder soportar la coordinación de todo el marco de trabajo (framework), marco de trabajo que se espera que soporte la interacción de los agentes y facilitar la propagación de la información. [92]
En igual forma, cada dispositivo hace parte del cluster en donde se espera hospedar la Cloudlet tendrán un sistema que logra la comunicación de los dispositivos que participan cada uno con el otro, también servirán como capa intermedia entre el nivel de aplicación y el sistema operativo. El presente trabajo de investigación, propone una capa intermedia que puede ser instalada sobre el sistema operativo de los dispositivos móviles y serán capaces de ejecutar las aplicaciones en todos los dispositivos. [13]
Para el presente trabajo de investigación, se diseñó una capa intermedia Cloudlet, la cual está compuesta por siete (7) capas (layers); diseño que se describirá posteriormente.
3 http://nodejs.org/
109
4.7. PROS Y CONTRAS
Pros:
A. Solo los usuarios autorizados pueden acceder a la información, en cambio, los usuarios no autorizados no podrán saber nada de la información.
B. Mobile Cloud Computing (MCC) es una de las tecnologías móviles con más tendencia en el futuro, esto debido a que combina la computación móvil y la Cloud Computing proveyendo servicios óptimos para los usuarios de tecnología móvil.
C. La administración de los datos reduce el costo de los servicios Cloud reduciendo los gastos en la comunicación y el almacenamiento (actualización, la carga).
Contra:
A. Las aplicaciones Cloud Mobile Media (CMM) al mismo tiempo que otras aplicaciones Cloud, requieren sobreponer los retos de las redes inalámbricas, incluyendo el ancho de banda y el impacto en la experiencia de los usuarios finales.
4.8. CASO DE USO
Para ilustrar el caso de estudio, considere una empresa de servicios públicos en la ciudad de Bogotá .D.C; particularmente, la Empresa de Acueducto, Alcantarillado y Aseo de Bogotá. En cualquier tipo de operación en campo, la empresa de servicios públicos despliega un equipo de trabajadores con un líder de grupo. El líder de grupo organiza, ordena y retroalimenta al grupo con información. En la actualidad, las empresas de servicios públicos proveen a sus grupos de trabajo con dispositivos móviles de detención y accionamiento debido al “bajo costo” de la tecnología y a la necesidad de mejorar la seguridad y la toma de decisiones en campo de sus operarios. Como resultado de este escenario, los operarios y sus líderes de grupo están habilitados con el fin de obtener un volumen grande de información en tiempo real, información como conocer la posición de cada uno de sus operarios, el entorno (sitios de interés), las condiciones de seguridad, la ruta de cada uno de sus operarios, entre otros.
110
Para nuestro caso de estudio, los grupos de operarios en campo, son equipados con detectores móviles y dispositivos de computación portátil (la energía depende de su batería) dispositivos que cuentan con conexión inalámbrica.
Figura 43. Caso de Uso
Fuente: Elaboración propia.
Para el caso de estudio, los dispositivos capturan información acerca del medio ambiente (humedad, ubicación, entre otros), y se comunican a través de una red móvil ad-hoc. Los dispositivos que portan los operarios en campo, en algunas ocasiones pierden la conectividad de la red inalámbrica, aunque estos dispositivos son independientes para realizar algunas tareas de computación; tareas que no demanden computación intensiva ni procesamiento intensivo de datos. En igual forma, existen centros de datos (data centers) en la vecindad de estos dispositivos móviles, los cuales no están restringidos en términos de la batería (energía) o en términos de poder computacional. En este orden de ideas, los dispositivos móviles debieran ser capaces de descargar las tareas que demandan alto consumo computacional en tiempo real hacia dichos centros de datos vecinos a los dispositivos móviles, de tal manera que, todo el sistema supera los riesgos inherentes, riesgos como aumento en la latencia, desconexión de la red, retrasos, tiempos de respuesta demasiado lentos o que se descargue la batería por el procesamiento de información geográfica.
111
En nuestro caso de uso, los ambientes Cloud accedidos a través de internet podrían emplearse para ejecutar tareas que no estén en tiempo real como análisis de grandes volúmenes de datos (Big Data), o podría emplearse para llevar a cabo agregación de información que permita coordinar otras brigadas en campo de otras empresas de servicios públicos o en un futuro poder entrenar un modelo de predicción, entre otras aplicaciones.
4.9. DISEÑO DEL MODELO
Para el desarrollo del modelo conceptual, se adoptó una variante de la metodología INSPIRE, esta variante se fundamente en procesos bien definidos y buenas prácticas de la ingeniera de software, El MODELO DE ACCESIBILIDAD MÓVIL A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL, conceptualmente consiste en Mapear y trasladar todas las capas de la Arquitectura lógica en una Arquitectura física y de despliegue.
Figura 44. Modelo de Accesibilidad móvil a Servicios de Información Geográfica en la Nube Computacional.
Fuente: Elaboración propia
112
El modelo es la representación sintáctica concreta que, existen infinidad de formatos y estándares, los cuales deben ser geo-procesados con el fin de obtener un resultado el cual es, la respuesta que espera el usuario final, en términos de aplicación. Este trabajo de investigación, surge como una necesidad de estrechar la brecha entre la academia y la empresa privada y entidades públicas y en particular en proyectos para la Gestión de Sistemas de información y Tecnología de Información y Comunicación TIC, se propone para el escenario real, una Cloud Computing hibrida (pública y privada).
4.9.1. Solución
Según se ha citado en la sección de capa intermedia, para el presente trabajo de investigación, se diseñó un modelo de capa intermedia (Middleware) Cloudlet, el cual está compuesto por cinco (5) capas (layers) de alto nivel. Posteriormente se mostrara el diseño del modelo a nivel de componentes, agrupando estos niveles por capas o layers.
La solución para el diseño del modelo se ha inspirado en el caso de uso acá expuesto, a las limitaciones y a los retos del escenario, además, se predice que la arquitectura propuesta podría servir como una plantilla o como una arquitectura de software de referencia, la cual podrá guiar la estructuración para el despliegue de aplicaciones en el campo de los Sistemas de Información Geográfico en la nube computacional móvil. Este acercamiento de capa intermedia (Middleware) se sugiere con el fin de abordar los temas relacionados con interoperabilidad y además, porque facilita el manejo de servicios que procesan datos de manera intensiva en los dispositivos móviles. [93]
El modelo (framework) es desarrollado de tal manera que de forma automática y dinámicamente puede distribuir varios componentes de una aplicación entre un dispositivo móvil y el servidor, con el objetivo de optimizar las diferentes funciones que interactúan al mismo tiempo como son: el consumo de memoria, la vida útil de la batería, la latencia, el ancho de banda, el costo en las comunicaciones, entre otros.
113
El modelo planteado se describe como una composición de componentes de software; estos componentes de software materializan los nodos identificados y sus vínculos materializan la dependencia entre nodos. Ahora bien, se parte del hecho que, el modelo Cloudlet será desplegado con la existencia de una infraestructura de internet; se implementara un servicio de agentes, el cual sigue fielmente el paradigma típico de agentes móviles.
Posteriormente, se implementara un servicio de descubrimiento por proximidad, implementado como servicio web, destinado a estar hospedado en un recurso computacional Cloudlet y, disponible por medio del API RESTful sobre el protocolo HTTP.
Sobre la base del acercamiento simple y distribuido propuesto por [94], en el presenta trabajo de investigación se implementó el algoritmo ampliamente usado Connected Dominating Set (CDS), este algoritmo establece un proceso de marcado, marcando cada nodo sobre un grafica G, asignando un T para el nodo ya marcado y una F para el nodo aun no marcado.
Para ilustrar esto, dada una gráfica conectada G en un tiempo T:
G = {V.E}, para cualquier nodo u,v, Є V
Se tiene que el conjunto V es el conjunto universal de nodos móviles; el conjunto D representa los nodos estables en CDS; C contiene todos los nodos en el conjunto V que no están incluidos en D, el conjunto R son los nodos ricos en recursos y el conjunto S es el grupo de nodos que ofrecen servicios cloud. Cada nodo con al menos dos (2) vecinos es marcado como T, es decir, todos los nodos marcados como T forman el grupo o el dominio mínimo y conectado para el conjunto D. Con el fin de encontrar el tamaño mínimo en el algoritmo CDS, los autores en [94] se refieren al conjunto de dominio mínimo conectado (Minimum Connected Dominating Set - MCDS).
114
Figura 45. Ejemplo del algoritmo CDS.
Fuente: [94]
Por ejemplo, como se aprecia en la figura 45, el conjunto de vértices {a, b, c} conforma un CDS, por lo tanto, son los vértices dominadores y {d, e, f} son los vértices a ser dominados. Encontrar el MCDS, es el planteamiento NP-Hard Garey y Johnson (1979) y muchos otros investigadores ya han realizado una extensiva revisión de los algoritmos. [95].
Se adoptó este algoritmo puesto que soporta escalabilidad, y en efecto, si un nodo se une como una extensión, este tendrá un nodo CDS a una distancia de un solo salto (hop), de lo contrario, el mismo se convertirá en nodo CDS si tiene dos nodos vecinos no conectados.
115
4.9.2. Metodología
A. Descripción del Modelo
El objetivo principal fue, diseñar un modelo que fuese escalable, confiable y con alto rendimiento. Con el modelo propuesto, se espera que estas características sean proporcionadas a un costo relativamente bajo comparando este costo con el costo de una infraestructura dedicada, como lo sería con un modelo Cloud distante y centralizado. El diseño del modelo se soporta sobre el concepto de una IDE (Infraestructura de Datos Espaciales) o por sus siglas en ingles Spatial Data Infrastructure (SDI), es decir, el principal punto de atención ha sido emplear un acercamiento práctico para explorar y extender el concepto IDE tanto en el sector de la academia como en al ámbito laboral Cloud.
El modelo propuesto y desarrollado sobre el concepto de una IDE habilitada para la Cloud, proveerá un medio eficiente y efectivo para compartir grandes volúmenes de información alfanumérica y geoespacial, empleando para ello la web de manera segura. El modelo SOA propuesto y basado en el concepto IDE, adopta el concepto básico de un proveedor de servicio, un consumidor de servicios y un catálogo de servicios.
El modelo propuesto en el presente trabajo de investigación se centra en la compatibilidad con el OGC (Open Geospatial Consortium) para servicios web de información vectorial y tipo raster. El usuario administrador del sistema administra los datos y proporcionara los privilegios a los diferentes usuarios, de igual manera, el catálogo de servicios será actualizado por el administrador del sistema. En el catálogo de servicios serán publicados varios servicios, los cuales estarán listos para responder la demanda de servicios de los clientes, clientes como las aplicaciones web o desarrolladores web que requieran servicios para sus aplicaciones.
Por último, esta arquitectura cumple con un flujo de trabajo sofisticado para el desarrollo de un modelo de Infraestructura de Datos Espaciales (IDE) con servicios web geográficos inclusive para dispositivos móviles.
116
A diferencia de las técnicas de integración por medio de comunicación basada en WS (Web Services), la cual se centra en funciones y emplean de manera simple el protocolo HTTP como protocolo a nivel de transporte para la funcionalidad a nivel de aplicación; las peticiones y respuestas del API REST en la transferencia de recursos y emplea el protocolo HTTP para construir de forma directa el protocolo de comunicación a nivel de aplicación. Como ya se ha aclarado, el presente trabajo de investigación, propone un esquema que construye un sistema descentralizado y de alto rendimiento por un grupo de dispositivos móviles voluntarios (red ad-hoc) los cuales se unen con el fin de formar una sola unidad de recursos (Cloudlet).
El aporte de esta idea fue, diseñar un modelo que interactúe como un recurso de acceso público entre dispositivos móviles cercanos geográficamente. Esta cloudlet, proveerá gran capacidad de almacenamiento y podrá ser empleada como un recurso computacional por otros dispositivos en la red. Por medio de los agentes, el sistema detectara el movimiento de los nodos participantes con el objetivo de, reestructurar la topología en caso que algunos nodos que están suministrando soporte a la cloudlet fallen o salten del alcance de la red de la cloudlet.
Este aporte se logra aprovechando el concepto de grupos dominantes virtuales para crear superposición en los deltas en la red y distribuir las responsabilidades en un servidor cloudlet. Debido a ello, se propone una arquitectura y se proponen algoritmos requeridos por esta arquitectura. Se mapean los recursos disponibles en la red asignando puntaje a cada dispositivo de manera individual, luego se toman estos puntajes para determinar el candidato más apropiado para los nodos cloudlet.
Según se ha citado, se diseñó un MODELO DE ACCESIBILIDAD MÓVIL A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL como capa intermedia Cloudlet, la cual a su vez, está compuesta por siete (7) capas (layers); la siguiente figura muestra el diseño a nivel de componentes agrupados por capas (layers) conceptuales.
117
Figura 46. Diseño Conceptual del Modelo propuesto
Fuente: Elaboración propia
Capa de usuarios y Dispositivos Móviles
Plataforma de Red Móvil
Ad-Hoc Cloudlets Middleware (Agentes
Móviles, otros códigos de aplicación, Administrador de
Recursos.)
CLOUD
RESTful Web Services (Servicio para
descubrimiento de proximidad)
Recursos (directorios, direcciones, estándares
OGC, entre otros)
Infraestructura de Hardware
AlfredO (Descarga de la aplicación)
Administración Cloudlet
Controles Cloudlet (CDS, backup, registro de
actividad)
Administrador Dispositivos
(balanceador, toma de decisiones, Agente de
nodos)
Kernel Capa intermedia (Middleware)
118
Con este modelo se configura una infraestructura de un computador o grupo de computadores (recursos) ricos en Georecursos en la vecindad del cliente, infraestructura denominada Cloudlet. Estos Cloudlets ofrecen servicios en caso de no haber conexión o en caso que la conexión a internet sea débil o en caso de no poder conectarse a los grandes proveedores de Cloud. [72].
La descarga de parte de la aplicación en dispositivos móviles cercanos ahorra en costos monetarios, puesto que se reduce el consumo de banda ancha; esto permite crear comunidades computacionales (ad-hoc) en las cuales los usuarios conforman un ambiente colaborativo con el fin de ejecutar tareas compartidas.
Dadas las condiciones que anteceden, el modelo propuesto se describe a continuación:
4.9.2.1 Capa (Layer) 1
Corresponde al área de dispositivos móviles, dispositivos conectados a las redes móviles a través de las estaciones base las cuales establecen y administran las conexiones (interface aérea) y las interfaces útiles entre las redes móviles y los dispositivos móviles. Las peticiones y los datos provenientes del área desde los usuarios móviles se transmiten al área de procesadores centrales conectados a los servidores suministrando servicios a la red móvil. En esta capa los servicios de red AAA (Authentication, Authorization, and Accounting)4, son suministrados por los Agentes de inicio (Home Agent - HA) los cuales soportan a los usuarios suscritos, la información de esta suscripción se encuentra en sus Bases de Datos. Es evidente entonces, que las peticiones provenientes del área los suscriptores se entreguen a la Cloud a través de la web.
Como puede observarse en el modelo propuesto, los contralores Cloud ofrecen en la Cloud, el método para las peticiones con el fin de proveer a los usuarios móviles con sus correspondientes servicios Cloud.
4 http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-2/102_aaa-part2.html
119
4.9.2.2 Capa (Layer) 2
Corresponde a la Plataforma de Red; se adopta el acercamiento teórico del Instituto Europeo de Estándares en Telecomunicaciones (European
Telecommunications Standards Institute - ETSI) conocido como Next Generation Network (NGN). Esta es una iniciativa global de la industria de telecomunicaciones, iniciativa que emplea estándares desarrollados por ETSI y el Sector de Estandarización de Comunicaciones de la Unión Internacional de las comunicaciones. La ventaja o aporte significativo de este acercamiento es, NGN ha sido diseñado para proveer interoperabilidad, dominio interno a todas las redes basadas en estándar IP y capacidades de multimedia. NGN ofrece acceso sin restricción a los diferentes proveedores de servicio. Este acceso sin restricción incluye, telefonía de voz, Virtual Private Networks (VPNs), servicios de datos, mensajería unificada, servicios de multimedia y redes para computación pública. El diseño de NGN soporta arquitecturas dinámicas por tanto, puede re-acomodar nuevos servicios a medida que estos son identificados.5
Figura 47. Siguiente Generación de Redes (Next Generation Network-NGN)
Fuente: The National Institute of Information and Communications Technology. Tokyo,
Japan.
5 http://www.itu.int/ITU-T/ Accedido en 07-12-2013).
120
4.9.2.3 Capa (Layer) 3
Corresponde a la Cloudlet; en una arquitectura Cloud tradicional, existen tres componentes básicos: Cliente Móvil, Canal de Transmisión y por supuesto la Cloud. Los clientes móviles solicitan los servicios requeridos a la Cloud y esta a su vez, provee los servicios. De los anteriores planteamientos se deduce que, en esta arquitectura la principal desventaja es la latencia en la comunicación para obtener los servicios requeridos desde las lejanas Cloud.
El aporte del modelo propuesto es la adopción de una arquitectura Cloudlet, según se ha visto, una Cloud local (Cloudlet) tiene en su caché una copia de los datos. La Cloudlet solo debe ser instalada entre los clientes móviles y la Cloud. El costo de esta instalación es mucho menor si se compara con el costo de realizar una instalación de una Cloud como un centro de datos para fines comerciales.
Otra ventaja de la Cloudlet es, solo ofrece servicios a pocos usuarios al mismo tiempo y, presenta menos latencia en la comunicación comparado con el tiempo de latencia de una Cloud lejana. [72]
• AlfredO; implementa tres mecanismos principales: primero, Un modelo de distribución basado en servicios de Software; para soportar un número ilimitado de interacciones de servicios entre los teléfonos móviles con otros dispositivos móviles. Segundo, arquitectura de servicios multi-capa, para configurar flexibilidad a la interacción entre los servicios y tercero, un modelo de presentación independiente de los dispositivos móviles para lograr independencia y proveer una interface personalizable. [85].
• Administración Cloudlet; contiene información de los recursos particulares que
requiere la aplicación que está siendo hospedada. La tarea principal de este componente es resolver si la aplicación requiere ser descargada en la Cloudlet o no. La toma de decisión de esta capa, inicializa el servicio de descubrimiento en el modelo Cloudlet propuesto.
121
• Controles Cloudlet; se divide en tres subcapas; primero, permitir al
dispositivo descubrir, inicializar y comunicarse con los dispositivos de su cercanía. Este recibe y envía peticiones de servicios desde y hacia otros dispositivos. Segundo, se configura un Connected Dominating Set (CDS), este almacena información de los dispositivos cercanos, recursos y ubicaciones más próximas. Se administra la actividad que los dispositivos móviles registran en la Cloud, es decir, información de las tareas que están siendo ejecutadas en la Cloud. Como resultado, se tendrán registradas las actividades en la Cloud y se detectaran los fallos de los nodos en caso de haberlos. Estos componentes pueden o no estar siempre escuchando la actividad de los nodos todo el tiempo, el comportamiento depende del rol que desempeñe el dispositivo en la red. Tercero, se inicializa el proceso de backup para los datos de la Cloud, si solo si, no existan recursos suficientes disponibles en la red.
• Administrador de Dispositivos; compuesto por una serie de herramientas que proporciona compatibilidad con dispositivos móviles para la Cloud a través de los agentes de nodo. Contiene información de los recursos disponibles y de los datos provenientes de diferentes sensores en el dispositivo. El balanceador toma la información que corresponde a la aplicación que se está ejecutando en el dispositivo y decide si existen los recursos suficientes para ofrecer a la Cloud. Esta información se pasa al componente de decisión, el cual se encarga de aceptar o rechazar la solicitud de servicio hecha al nodo. De esta forma, se configura el mecanismo para crear las peticiones en el caso que el agente nodo sea un cliente Cloudlet.
• El núcleo (Kernel) capa intermedia (Middleware); capa que soporta múltiples sistemas operativos, responsable de adaptarse a la tecnología del dispositivo móvil y facilitar las actividades de la Cloudlet suministrando información relacionada con el Kernel y ejecutando las tareas. En suma, limpiar los archivos del cache de las aplicaciones, programación de las tareas y, demás actividades Cloud que requieren estar soportadas por un sistema operativo.
122
4.9.2.4 Capa (Layer) 4
El modelo propuesto plantea una arquitectura basada en el paradigma Mobile Cloud Computing (MCC) empleando el concepto Cloudlet. Los usuarios móviles instancian una Cloudlet en una infraestructura cercana y se usa vía red LAN inalámbrica.
El algoritmo ampliamente usado Connected Dominating Set (CDS) se implementó con base en los conceptos de Ad-hoc On-Demand Distance Vector Algorithm (AODV), la propuesta que este trabajo adopta es, Sistema de Adquisición por demanda de ruta; los nodos que no están en una ruta activa no mantienen información y no participan en las tablas de intercambio de ruteo periódico. En efecto, un nodo no tiene que mantener y descubrir una ruta hacia otro nodo hasta que dos nodos requieran comunicarse a menos que, el nodo formado este ofreciendo sus servicios como estación intermedia de envío con el objeto de mantener conectividad entre dos nodos. [96]
AODV, emplea un mecanismo de descubrimiento de ruta por emisión, de la misma manera como lo usa el algoritmo de Enrutamiento Dinámico de la Fuente (Dynamic Source Routing - DSR); en otras palabras, AODV depende de establecer dinámicamente registros de ruteo en las tablas de los nodos intermedios. Para mantener la información más reciente del ruteo entre los nodos, se adopta el concepto de Números de Secuencia de Destino (Destination-Sequenced Distance Vector routing - DSDV). El proceso descubrimiento de la ruta se inicia siempre que un nodo origen requiera comunicarse con otro nodo para los cuales no exista información en su tabla. Cada nodo mantiene dos contadores separados: un numero de secuencia de nodo y un ID (broadcast id). El nodo origen inicia el descubrimiento de la ruta dispersando un paquete a sus vecinos solicitando una ruta (Route Request - RREQ). Así mismo, RREQ contiene los siguientes campos:
123
De todo esto se desprende el uso en el presente trabajo de investigación del protocolo de ruteo basado en el grupo de dominio; se adopta el protocolo AODV con el fin de crear un Connected Dominating Set (CDS). Como ya se ha aclarado, un CDS de cualquier topología es una colección de nodos confiables que forman una red superpuesta. Se emplea el algoritmo CDS puesto que se considera como una manera organizada de reducir la sobrecarga de mensajes de control. Además, es una forma eficiente de reducir temas relacionados con la difusión y multidifusión como recibir el mismo mensaje muchas veces y reduce el desperdicio del ancho de banda. Optimizando el número de mensajes que transferidos entre nodos, se administra de manera eficiente la energía, reservando energía para los nodos. [97]
A manera de resumen, AODV es un protocolo de ruteo reactivo; es decir, un nodo generara un mensaje para petición de ruta RREQ si tiene que trasmitir el tráfico a un nodo huésped que no tiene ruta. RREQ se desbordara porque está limitado por los mensajes de otros nodos. Esto genera una sobre carga de trafico de control dinámico lo cual genera a su vez, un retardo cuando se inicia cualquier comunicación.
Entonces, una ruta se adiciona cuando el mensaje RREQ alcanza su destino o un nodo intermedio con un registro valido de ruta para el destino. Mientras exista una ruta entre dos puntos finales AODV permanecerá inactivo; cuando la ruta se pierda o sea inválida AODV de nuevo generara una petición. Existen otros mensajes como RREP (Route Replay message) que va desde el destino hacia la fuente y Route Error (RERR) para notificar cuando se detecta que el enlace se ha roto.
Para mayor conocimiento, Navjot Kaur realizo un análisis y una comparación entre RREQ y RREP (Route Replay message) y, Clifton Lin, tiene una implementación para ruteo AODV.
124
4.9.2.5 Capa (Layer) 5
Corresponde al Servicio por Descubrimiento; los nodos móviles requieren estrategias para descubrir la presencia de cada uno de ellos en la red y establecer servicios de red funcionales. Debido a la ausencia de una unidad central, el
modelo propuesto en el presente trabajo de investigación, emplea un Servicio de
Descubrimiento por proximidad geográfica.
El servicio tiene dos componentes que se encuentran en la Cloudlet; un índice espacial que mantiene el rastro con la ubicación de los recursos y, un API REST que posibilita el almacenamiento y la recuperación de manera remota de los recursos por medio de una conexión internet. El servicio expone una API mínima REST con el servicio (p.ej: rutas). Esto se planteó para facilitar el descubrimiento de recursos que estén geográficamente cercanos dejando otras funciones específicas de la aplicación a las propias aplicaciones.
Las peticiones POST de los dispositivos; cuando un cliente que puede ser un agente de software o, un sensor embebido o un dispositivo móvil, emite la petición a una instancia del servicio de descubrimiento con el fin de crear o actualizar el recurso que representa al cliente en la Cloudlet.
La petición tomar vecinos (GET); el cliente emite esta petición con el objeto de consultar a la Cloudlet por recursos que sean vecinos o estén cerca geográficamente. Esto se logra por medio de una aplicación, además, se puede limitar el rango de consultas que se pueden realizar en un espacio geográfico determinado. Es decir, se parametriza la petición con un rango que limite las consultas a un espacio geográfico de búsqueda. Una vez se ha recibido la respuesta, esta consulta contendrá una lista de recursos que se estima estén dentro del rango solicitado por el cliente móvil.
Considere el siguiente ejemplo, en donde un espacio geográfico determinado se descompone en regiones, para el caso en particular, estas regiones se denominaran Áreas Administrativas.
125
Figura 48. Área Administrativa Cloudlet
Fuente: Elaboración propia a partir de [5]
Para cada área administrativa existe una Cloudlet, la cual está encargada de responder a las peticiones de dicha región. El punto en el centro del círculo punteado representa un cliente móvil que se ha desplazado a lo largo de la línea punteada en un periodo de tiempo. A medida que el cliente móvil se desplaza ejecuta una petición de tipo POST, esta petición se envía con la localización actual del cliente hacia la Cloudlet encargada en esa área administrativa. En ese instante de tiempo, el cliente móvil descubrirá los recursos cercanos geográficamente dentro de una distancia de radio R, de esta forma, realizara una petición de tipo GET hacia sus vecinos de la Cloudlet”n”, donde “n” representa el número de la Cloudlet involucrada.
Es conveniente que existan mecanismos de sincronización, con el objeto de facilitar esta sincronización, el servicio de descubrimiento por proximidad, implementa una tercera ruta de recursos:
Cloudlet 1
Cloudlet 2 Cloudlet 3
126
Franjas de peticiones POST de los dispositivos; se realiza cuando una Cloudlet vecina ejecuta una petición para comunicar el conocimiento de los recursos existentes en el borde o cerca al borde de otra área administrativa adyacente. Las
franjas son una porción del espacio con una longitud “ɸ”. Periódicamente el servicio calcula cada una de las franjas para asimilarlas o tener una imagen de los recursos de la franja, lo cual envía a la Cloudlet adyacente apropiada vía servicio tipo peticiones de franja POST.
Figura 49. Franjas Áreas Administrativas
Fuente: Elaboración propia a partir de [5]
Para ilustrar lo anterior, en la gráfica se observa que la Cloudlet2 calcula la franja A y asimila {3, 4, 5} y envía una petición POST a la Cloudlet3. Ahora bien, el servicio presenta tres (3) variables como parámetros para el despliegue, parámetros que deben ser configurados de acuerdo a las necesidades particulares del caso de estudio.
127
T – Intervalo de tiempo que tarda la franja en asimilar y realizar los cálculos.
Ɲ - Representa el número de Áreas Administrativas, es decir, las Cloudlets en las que un espacio geográfico ha sido descompuesto.
ɸ - Distancias de las franjas de las Áreas Administrativas.
Adicionalmente, la ubicación puede llegar a ser una tarea costosa en términos de batería para los dispositivos móviles que se les solicita recursos, sin embargo, los métodos de localización actualmente están muy activos en el área de investigación. [5]
4.9.2.6 Capa (Layer) 6
Corresponde a los Recursos, tal como se ha visto, los recursos mínimos que se esperan en un cualquier Cloud Computing son: memoria, almacenamiento, la energía, CPU, la ubicación y la capacidad de almacenamiento en los dispositivos móviles. La sección 4.4 describe como son empleados los recursos en la toma de decisiones.
4.9.2.7 Capa (Layer) 7
Corresponde a Infraestructura de Hardware, la capacidad de almacenamiento y el poder de procesamiento aun es una preocupación seria en los dispositivos móviles. El paradigma Mobile Cloud Computing (MCC) se desarrolló con el fin que los usuarios móviles puedan almacenar y puedan acceder a grandes volúmenes de datos en la Cloud.
El modelo de servicios Cloud Computing de aplicaciones elásticas posibilita que esto sea escalable mediante el aprovisionamiento dinámico de recursos, por el autoservicio, sin que los usuarios tengan que diseñar aplicaciones que administren o balanceen los de pico de demanda de recursos.
128
4.9.3. Arquitectura
Figura 50. Arquitectura del Modelo propuesto
Fuente: Elaboración propia
129
4.9.4. Algoritmos
Según se ha citado, la gestión de la configuración en los dispositivos móviles se basa en la tecnología de agentes, tecnología que ha sido desarrollada durante varios años; ahora bien, como la nube móvil (Mobile Cloud) aún está en su primera década con muy poca investigación al respecto, la tecnología de agentes se ha convertido en la tecnología para administrar la Cloudlet. Por las consideraciones anteriores, el modelo propuesto parte del hecho que el usuario de la Cloudlet, debe ser un usuario autenticado con una dirección IP valida (protocolo TCP) cuando acceda a la Cloud y a la tabla de ruteo.
Sobre la base del isomorfismo que se presenta entre las redes P2P y las redes móviles Ad-hoc (MANET), diferentes grupos de investigación se han concentrado en el trabajo basado en la combinación P2P y la estrategia de núcleo virtual, esta combinación genera un campo de investigación llamado redes móviles P2P (Mobile peer-to-peer - MP2P).
Con respecto a la capa de agentes móviles, se adopta el siguiente algoritmo (pseudo código), el cual describe la funcionalidad implementada.
Algoritmo 1. Tomado de [98]:
1. Receive request (service).
2. Check (User Privet Key)
3. If (Not Trusted) : display (Error message).
4. Else:
• Update routing data();
• bandwidth = detect bandwidth();
• Service Type = read Service request ();
• Service Info = Service [Service Type].Full info \\ service ID, Sequence Number, default delay, resources needs, default cost, priority.
5. Call Application Recognition Procedure (Service type, Service Info, bandwidth);
6. Service Info = Service Info + tasks Info;
7. If (Buffer & j) then Call Scheduling Procedure (Service Info, Buffer ).
130
8. If (Buffer)
9. Reassemble the service (tasks).
10. Reply user();
Los siguientes sub-procedimientos son usados en el algoritmo anterior:
//Structure Application Recognition Procedure \\ Return Structure [Buffer , j, Task info]
Structure Buffer; int j=0;
If (Service Type exist) then
Select fragment methodology(Service Type);
Tasks = extract tasks();
Task info = for each task Encapsulate (TasksID. service info)
Else,
Launch a mobile agent(Trip bath, necessary Service Type information);
Update database ();
Return Buffer = Fill buffer (tasks, j=1)
//Structure Scheduling Procedure:
Structure schedule, Buffer;
schedule =Extract Scheduling info.Access buffer (Service Info, Fill Buffer);
Send_to_collaboration agent ( service Id, number of tasks)
Send_to_ offloading agent (all_tasks).
Set i = number of tasks
Set task [] = all_tasks;
cost = Cost_offloading (latency, bandwidth)
If (cost > main cloud or close cloudlet cost ) then reply "perform tasks on the main cloud".
131
Else, While ( i > 0 ) Start_ achieve task(i)
Check recourses need = Open task();
Selected device = Access devices database();
schedule = Hash function (task (i) , Selected device);
End while (i= i-1);
SendTo_monitor device agent(schedule);
All Tasks = Call Check-Status procedure(task i, device i)
Buffer =Fill Buffer (All Tasks has same service ID)
If cloudlet has not enough resources.
Hot spot agent. Lunch agent Looking Out(trip, recourses needs) back to step 5;
Return Buffer;
//VAR Check-Status procedure:
Task Status= for each device (Communicate MobileOS(Back task status)
Device Status= for each device (Communicate MobileOS(Back device status)
for all tasks i=1 to i= tasks number
1. If (Task Status =FIN) and (Device Status=OK), then
• Send_to_collaboration agent (task i)
• If (collaboration agent (Arrived all tasks has same serviceId)),then send to main scheduler.
2. Else (failure happened)
• Reallocate (task at arrived statues) to another device.
End for
La sección 4.9.1 describe el algoritmo empleado para crear el núcleo virtual en la red. Se empleó el concepto Connected Dominating Set (CDS) basado en un acercamiento distribuido y simple propuesto por [94].
132
Este algoritmo se soporta en un proceso de marcado, asigna una T para el nodo ya marcado y una F para el nodo sin marcar. Así mismo, los dos componentes críticos en cualquier algoritmo de ruteo son: selección de la ruta y la estrategia para establecer el orden de secuencia.
Algoritmo 2: Crear Connected Dominating Set (CDS)
Estado E = {Entrante, Activo, Terminado}
Estado_i = {Entrante}
Estado_f = {Terminado}
ID corresponde al nodo id, Ve(ID) es el grupo vecino de ID.
Nodo Entrante:
Aleatoriedad
Pasar a Activo
enviar(Guía) a todos los nodos dentro del rango de la transmisión
Marcado : Falso
Cuando está Activo:
Si recibe(Guía) entonces
Ve(ID) = Ve(ID) + transmisor
enviar(Ve(ID)) to transmisor (TransmisorVe)
Fin si
Si recibe(TransmisorVe(ID)) entonces . recibe vecinos de un nodo vecino
resultado = VecinosNoConectados(Ve(ID);TransmisorVe(ID)
Llamar funcion1
Si resultado entonces
Pasar a Terminado
enviar(ID) to Ve(ID)
Marcado = Verdadero
Fin si
Fin si
133
Funcion1 VecinosNoConectados(Ve(ID);TransmisorVe(ID))
asignar conectado = Falso
Para todo x : nodos en Ve(ID) ejecutar
Para todo y : nodos en TransmisorVe(ID) ejecutar
Si x = y entonces
conectado = Verdadero
Fin si
Fin para
Si conectado <> Verdadero entonces
devuelva Verdadero
Fin si
Fin para
devuelva Falso
Fin funcion1
Cada nodo involucrado, calcula su estado de acuerdo al algoritmo, cuando un nodo asume un estado, lo envía a los nodos vecinos CDS a una distancia de un Hop. Los nodos del grupo dominante selecciona los estados de los nodos vecinos seleccionando el mejor como su candidato Cloud y lo adiciona al grupo E.
Todos los nodos intercambian su información con todos los vecinos; con el algoritmo CDS, cualquier nodo con al menos dos vecinos no conectados se convertirá en un nodo CDS. Cada nodo CDS elegirá su candidato Cloudlet, además, todos los nodos CDS tendrán un conocimiento en común de la cantidad de recursos en la red.
134
Cuando un nodo requiera usar los servicios Cloud, envía una petición as sus nodos vecinos CDS, luego determinara si la petición puede realizarse localmente en su propia red o, tendrá que externalizar la petición. No obstante, si la red presenta las capacidades para servir la petición, el nodo CDS determina a cual nodo Cloudlet se le asignara la responsabilidad y en consecuencia, se le dará la ruta de los paquetes con la solicitud.
Ahora bien, cuando las peticiones son liberadas en la Cloud a través de la web, el modelo propuesto emplea el paradigma SaaS de nube computacional (computational clouds) para acceder a los servicios de los nodos servidores de la Cloud en función de la demanda de servicios. El modelo propuesto se centra en la descarga de tareas computacionales dinámicas al nodo servidor Cloud en lugar de, la migración intensiva de partición dinámica en el servidor de la Cloud. Cabe decir que, en las aplicaciones tradicionales de cliente ligero como aplicaciones de correo electrónico o aplicaciones web, el procesamiento lógico de la aplicación se hospeda en nodos de servidores remotos y las aplicaciones solo ofrecen una interface de cliente.
El modelo propuesto utiliza replicación de componentes intensivos de las aplicaciones móviles en el dispositivo móvil y el nodo servidor de la nube; además, emplea dos maneras diferentes de operar para la ejecución de la aplicación móvil: modo en línea y modo desconectado.
El modo desconectado en la ejecución de la aplicación representa el estado ideal en donde los recursos computacionales están disponibles localmente en el dispositivo; el modelo evalúa entonces la disponibilidad de recursos (Batería, RAM, CPU) y posteriores peticiones de ejecución de otras aplicaciones. La aplicación móvil pasara al modo conectado cuando los servicios de procesamiento de la aplicación solicitan a la nube computacional (computational clouds) para la ejecución de los componentes intensivos de la aplicación móvil. Los datos de entrada requeridos son transmitidos al nodo servidor Cloud; si la tarea es exitosa en el nodo servidor de la nube, la información con la respuesta exitosa se devuelve al dispositivo móvil.
135
La aplicación es capaz de operar como una aplicación solitaria en modo desconectado y tiene la capacidad de acceder a los servicios Cloud distribuidos en modo conectado.
Finalmente, se describe el ambiente empleado para realizar el experimento computacional, luego se discutirá el experimento y las observaciones. El presente trabajo de investigación propone una arquitectura IDE basada en Mobile Cloud Computing.
Asimismo, cuando los usuarios móviles de la aplicación basada en Cloud primero se conectan al modelo propuesto y luego el modelo conecta al usuario al recurso Cloud apropiado en un corto tiempo empleando el algoritmo de manera que el usuario móvil se conecta de manera fácil a la aplicación basada en Cloud.
El simulador de red empleado fue NS3 simulator 6 sobre el IDE Eclipse-CDT 7, las pruebas de la aplicación prototipo se realizaron en dispositivos móviles Android en un ambiente real Cloud Computing. El modelo SaaS de nube computacional se empleó para el aprovisionamiento de servicios para los dispositivos móviles.
El dispositivo móvil accede la red inalámbrica vía conexión de radio Wi-Fi de tipo 802.11 g, con un layer físico disponible de datos de 54 Mpbs. Para la aplicación prototipo se utilizó software de desarrollo de Java para Android (Android SDK); Power Tutor tool 8 se usó para medir el consumo de batería en el procesamiento distribuido de la aplicación y para la información relacionada con la memoria, capacidad de disco y CPU se empleó Passmark 9.
6 http://www.nsnam.org/.
7 http://www.eclipse.org/cdt/.
8 https://play.google.com/store/apps/details?id=edu.umich.PowerTutor&hl=en.
9 http://www.passmark.com/products/pt_mobile.htm.
136
Tabla 3. Parámetros de Simulación
Parámetro Valor
Protocolo AODV
Ruta Activa tiempo de espera 03 segundos (Defualt)
Área de Simulación (m2) 2000 _ 2000, 6000 _ 6000, 10000 _ 10000,
Protocolo WLAN 802.11g
Tiempo de Simulación 100 segundos
Rata de Bits 11 Mbps
Numero Nodos 23, 70, 120
Distancia cobertura estación 100 meter
Antena Omni Directional
Poder de transmisión estación 0.05 mW
Energía Inicial por nodo 1.1 J
Velocidad de movimiento estación 0m/s, 4m/s, 10m/s
Modelo de Energía WiFi Radio Energy Model
Tipo de codificación Constant Bit Rate (CBR)
Velocidad Máxima en (m/seg) 2,8, 15
Paquete inter-hora llegada 0.25 segundos
Modelo de Movilidad RWPM
Tamaño del Paquete 64 byte (512 bits)
Simulador de red NS 3
Batería 60%
Trafico hora inicio de generación [0,10] with uniform distribution
137
4.9.5. Algoritmo Propuesto
Con los parámetros anteriores, se obtiene una estimación razonable de los dispositivos móviles que podrían estar presentes en un instante de tiempo dado en una vecindad cualquiera. Cada nodo en la red (ad-hoc) representa un dispositivo móvil real. De igual manera, cada dispositivo contiene todos los recursos y el valor de cada recurso se determina de manera aleatoria.
Figura 51. Algoritmo propuesto
Fuente: Elaboración propia
138
El algoritmo propone una arquitectura IDE basada en Mobile Cloud Compuitng, cuando un usuario móvil desea acceder a la aplicación basada en Cloud primero se conecta al modelo propuesto y luego el modelo conecta al recurso Cloud apropiado. En el modelo, los dispositivos móviles se conectan a las redes móviles a través de las estaciones base (ver arquitectura). Luego, los usuarios móviles realizan una petición en donde su información, que para el caso en particular es el ID y la ubicación, se trasmiten a los procesadores centrales los cuales están conectados a los servidores que proveen servicios de redes móviles. En este punto, el operador de red móvil a su vez provee servicios a los usuarios móviles como AAA (Authentication, Authorization, and Accounting) basado en agentes (Home Agent – HA) y en la información de los usuarios en la Base de Datos. Posteriormente, las peticiones de los usuarios se envían al modelo propuesto y este conecta a la ubicación Cloudlet apropiada a través de la conexión a internet.
En síntesis, el algoritmo es de la siguiente manera:
� Recibir petición usuarios móviles.
� Cloudlet almacena información de los nodos Cloud disponibles, información como dirección IP, capacidad, distancia y ruta más corta.
� Todos los nodos Cloud envían información de forma periódica a la Cloudlet, capacidad de almacenamiento y capacidad del canal.
� Comparar capacidad del canal, si es igual a cero, detenerse; sino continuar.
� Comparar fuerza de la señal, tomar la señal más débil con la misma capacidad de canal.
� Sino, retornar al punto de comparación capacidad de canal hasta encontrar otro nodo.
� Hacer lista de nodos Cloud y enviar a la Cloudlet.
� Existe petición nuevo nodo remoto?
� Hacer lista alterna de nodos Cloud y almacenar en la Cloudlet.
� Validar cual es el mejor nodo. Es el mejor nodo? No? Retornar lista alterna.
� Para mejor nodo seleccionar nodo y enviar dirección a la Cloudlet.
� Realizar la conexión y Finalizar.
139
4.9.6. Consistencia
En cuanto a la consistencia de los datos, la consistencia se garantiza ya que las bases de datos Geográficas son replicadas y estarán siempre en el mismo estado, o en términos de B.D. siempre estarán en la misma versión. Adicionalmente la consistencia es garantizada mediante la capa de persistencia del catálogo de metadatos.
4.9.7. Discusión
En el presente trabajo de investigación se abordó la arquitectura Mobile Cloud Computing (MCC), paradigma que ayuda a los usuarios móviles a conectarse a recursos Cloud y ayuda en la búsqueda de recursos Cloud en un muy corto periodo de tiempo. Con el uso del modelo propuesto se obtiene una mínima utilización de los recursos de los dispositivos móviles inteligentes cuando se realiza la descarga de procesamiento computacional en Mobile Cloud Computing (MCC).
El tiempo para el cambio de la tendencia, el tamaño en la transmisión de los datos y el costo para el consumo de energía en los dispositivos móviles inteligentes se reducen en las aplicaciones móviles de procesamiento intensivo en el nodo servidor de Cloud. Empleando el modelo propuesto el tamaño en la transmisión de los datos en la búsqueda de servicios Cloud se reduce un 75.2% y, el tiempo para el cambio de tendencia en la operación de búsqueda se reduce un 90%, finalmente, el consumo de energía se redujo en un 85.3% en comparación con las técnicas tradicionales de descarga de la aplicación en le Cloud.
Debido a que los datos están almacenados y son administrados en la Cloud, la seguridad y la privacidad depende de proveedores de IT de la dicha Cloud. Es de anotar que, la información almacenada en la Cloud debe considerar estas características de privacidad y seguridad
140
El presente trabajo de investigación se centra en la adopción de estándares del Open Geospatial Consortium (OGC) para compartir, crear, integrar y acceder los recursos Mobile Cloud Computing en la web. El modelo desarrollado adopta una estructura flexible y modular proveyendo un mecanismo eficiente para desplegar y generar valor a la información espacial y extender de esta manera, el concepto de servicios web geoespaciales en el campo de las comunicaciones móviles y, aportando al requerimiento de una Infraestructura de Datos Espaciales a nivel regional. Es evidente entonces que, el modelo desarrollado e implementado aporta una Infraestructura de Datos Espaciales basada en una arquitectura orientada a servicios web y habilitada para Mobile Cloud Computing.
En los resultados experimentales se aprecia que la red no muestra signos de formación Cloud en caso de haber muy baja velocidad de nodo. Las redes en áreas pequeñas son ideales para un número pequeño de nodos. Los enlaces de comunicación duran más para velocidades bajas, sin embargo, están en rangos aceptables inclusive para redes mucho mas dinámicas.
Por todo lo dicho, el modelo computacional experimental se diseñó, desarrollo e implemento empleando una Arquitectura bajamente desacoplada. Cada uno de los módulos y de los componentes fueron desarrollados por diferentes comunidades, tanto comunidades de software libre como por software comercial, los cuales difieren tanto en sus metas comerciales como en sus objetivos específicos de diseño.
Para algunos lectores, el modelo computacional experimental a simple vista puede ser visto como paradigma SaaS y PaaS en el modelo Mobile Cloud Computing, sin embargo, este no se debe tomar a simple vuelo de pájaro, puesto que el diseño en la arquitectura del prototipo computacional experimental por ahora solo está limitado al consumo de geo-servicios para el Geo-procesamiento de grandes volúmenes de datos (Big Spatial Data) desde los dispositivos móviles en la nube computacional; por lo cual y a futuro, este diseño es altamente escalable a un ambiente de producción empresarial provisto de una infraestructura similar a la del laboratorio de alto desempeño computacional.
141
4.9.8. Escalabilidad
La escalabilidad del sistema está garantizada por la implementación de una arquitectura SOA, la cual está compuesta por n capas, donde n=3, y estas capas pueden crecer dependiendo de la demanda de servicios. Debido al tipo de arquitectura a implementar, en la medida que la demanda crezca se adicionara un nuevo geo-servicio, agregándose un módulo más. Esto es debido a que los módulos son altamente desacoplados puesto que son implementados bajo el paradigma de geo-servicios Web, los cuales se pueden expandir sin importar el número. El sistema es escalable ya que se corroboró que este conserva su efectividad al ocurrir un incremento considerable en el número de recursos y en el número de usuarios.
4.9.9. Trabajo Futuro
Después de lo anterior expuesto, la Base de datos empleada en el modelo propuesto está en un nivel macro, pero puede ser investigada de manera más exhaustiva en estudios futuros.
Se ajustara el caso de uso acá expuesto basado en un largo periodo de pruebas, además, se experimentara con un gran número de servicios de movilidad y se integrarán hacia la realización de servicios de movilidad multimodal a través de nuestro modelo. Como trabajos futuros también se planea realizar diferentes experimentos empleando diferentes instancias de arquitecturas de referencia de la arquitectura acá propuesta con el fin de evaluar el desempeño y latencia.
El presente trabajo se extenderá para desplegar Cloudlets mucho más estables y de mayor longevidad de red distribuyendo las responsabilidades y funciones con respecto a la carga en el dispositivo móvil y el nivel de red. Como trabajos futuros, la investigación está encaminada hacia los SIG móvil en la nube computacional; además de esto, se deberá desarrollar nuevas herramientas, desarrollar aún más la arquitectura y basados en esas nuevas arquitecturas, desarrollar aplicaciones que se integren y sean interoperables entre sí de manera autónoma e inteligente.
142
4.9.10. Relación entre el Nodo de la Universidad Distrital F.J.C. y el Modelo Computacional Propuesto
Cloud Computing es un término actual y una de las últimas tendencias en tecnologías de la información, sin embargo, el paradigma de Infraestructura de Datos Espaciales - IDE o del inglés Spatial Data Infrastructures (SDIs) no ha sido abordado en su totalidad desde el punto de vista de la Nube Computacional y por consiguiente, aun menos desde el punto de vista del paradigma Mobile Cloud Computing (MCC).
Hace algunos años atrás, el procesamiento de grandes volúmenes de datos geográficos, se ejecutaba en computadores personales o en servidores centralizados conocidos como mainframes; debido a la demanda masiva por el procesamiento de grandes volúmenes de información, el paradigma de Nube Computacional es un acercamiento prometedor. Esta tecnología es de gran beneficio para el escalamiento de las grandes tareas de procesamiento dentro de una infraestructura en una organización gubernamental o privada o sobre una Infraestructura de Datos Espaciales (IDE). [99]
Actualmente, muchos usuarios crean y comparten con otros usuarios su información espacial por demanda y de manera masiva también, esto se convierte en una aplicación muy beneficiosa para una IDE puesto que enriquece las bases de datos existentes en tiempo real. Con esto, se puede afirmar que, la Nube Computacional (Cloud Computing) es una gran oportunidad técnica y económica para las IDEs con el fin de brindar soporte a las futuras aplicaciones geoespaciales. Excelente para la creación de nichos de negocio para crear, operar y utilizar IDEs. Todos estos aspectos motivan a los investigadores de las ventajas potenciales de emplear la Nube Computacional en una Infraestructura de Datos Espacial (IDE). [101]
143
De acuerdo con [102], el paradigma Cloud Computing se superpone con algunos otros conceptos como Computación Distribuida y Computación GRID; este último, se aplica a las comunidades científicas (como la Universidad Distrital F.J.C.) para el procesamiento computacional a escalas grandes.
En tal aspecto, el CECAD concierne con el modelo computacional acá propuesto, en relación que esa infraestructura tecnológica podrá integrarse en una IDE local y por ende en una IDE regional, llegando a ser un escenario Cloud Computing que posibilite, a compañías pequeñas o medianas del Distrito de Bogotá, desplegar sus aplicaciones web de una forma instantánea y escalable sin la necesidad de invertir en grandes infraestructuras computacionales, que faciliten el almacenamiento de grandes volúmenes de información y que a la vez sean capaces de ejecutar procesos complejos, para el caso en particular, geoprocesos (georecursos).
El modelo computacional experimental propuesto en el presente trabajo de investigación, propone la infraestructura GRID del CECAD como un paradigma de outsourcing de aplicaciones, geoprocesos y tareas específicas en una infraestructura escalable posibilitando la creación de nuevas oportunidades de negocio con una relativa baja inversión; es decir, existe un gran potencial para futuros modelos de negocio con la información geoespacial.
Por estas razones, el presente trabajo de investigación, considera al CECAD como un nodo que hace parte de una IDE (red MANET), aplicando los conceptos de IDE y Cloud Computing, con el objeto de mapear esa infraestructura en nube computacional y por ende, en una Nube Computacional Móvil (MCC) habilitada con los beneficios y ventajas del paradigma Cloud Comnputing.
Como se ha expuesto en el presente trabajo de investigación, el paradigma de nube computacionl (Cloud Computing) reemplazó al clásico modelo de arquitectura multi-nivel (multi-tier) de servicios web creando, un nuevo grupo de capas (layers).
144
A continuación se muestra los posibles usos MANETs en las futuras redes 4G. [100]
Figura 52. Integracion MANET (Mobile Ad Hoc Network)
Fuente: [100]
En este escenario, se muestra al CECAD de la universidad Distrital F.J.C. como un posible nodo de comunicación IDE integrado, interoperable y habilitado con el paradigma Cloud Computing; es decir, se integra el paradigma de Nube
Computacional con el concepto de Infraestructura de Datos Espacial (IDE) en nuestro entorno Colombiano, logrando acortar la brecha en tecnologías de la información existente en nuestro país.
145
En el escenario anterior, se observa a usuarios móviles fuera del rango de cobertura de cualquier punto de acceso inhalambrico LAN, o fuera de la cobertura de cualquier red celular 3G; sin embargo, los usuarios continúan comunicándose con sus correspondientes nodos (para el caso en particular el nodo CECAD) en internet por medio de las redes creadas gracias al multi-hop de las redes ad-hoc que residen dentro de la misma cobertura MANET. [100]
De esta manera, se podrá integrar el CECAD dentro del modelo propuesto, convirtiéndose en una arquitectura IDE integrada y habilitada con el paradigma Cloud Computing. Como se menciona un poco mas arriba, por medio de agentes, el sistema detectara el movimiento de los nodos participantes con el objetivo de, reestructurar la topología en caso que algunos nodos que están suministrando soporte a la cloudlet fallen o salten del alcance de la red de la cloudlet (integración e interoperabilidad Movil Cloud Computing), garantizando la comunicación para el descubrimiento, consumo y publicación de Georecursos.
El punto de falla, el tiempo roto en la comunicación, el retraso, promedio de tiempo de interrupción en la comunicacion y algorimtos de analisis, han sido ampliamente estudiados en [100] y se adoptan en el presnete trabajo de investigación. Sin embargo, como aun es un tema de investigación que se ha abordado muy poco en nuestro entorno Colombiano, existen también algunos obstáculos para desarrollar una IDE integrada, interoperable y habilitada con el paradigma Cloud Computing. Algunos de esos obstáculos son:
Uno de los mayores obtsaculos es el hecho que los proveedores Cloud carecen de interoperabilidad entre otros proveedores Cloud en términos de las APIs de desarrollo, lo cual es un gran obstáculo al momento de querer migrar de una nube a otra. Esta restricción se debe a que diferentes peroveedores Cloud internamente atienden diferentes requerimientos y capacidades, lo cual dificulta a los proveedores de georecursos migrar entre Clouds y más aún, configurar los georecursos en los diferentes proveedores de Clouds. [102]
146
4 CONCLUSIONES Y RECOMENDACIONES
5.1 RECOMENDACIONES Y LINEAMIENTOS PARA EL DESARROLLO FUTURO DEL MODELO DE ACCESIBILIDAD A SERVICIOS DE INFORMACIÓN GEOGRÁFICA EN LA NUBE COMPUTACIONAL (NODO) IDE.
1. El grupo de investigación NIDE (Núcleo de Investigación en Datos Espaciales), grupo líder en el análisis espacial de la Universidad Distrital, deberá realizar las respectivas solicitudes de presupuesto y recursos ante la Universidad para contar con este Nodo IDE.
2. Esta iniciativa debe provenir como una política o lineamiento institucional que la respalda, tanto es su implementación como en su mantenibilidad.
3. Se debe realizar un análisis con las entidades del distrito para conocer sus necesidades de información con respecto a lo producido por la universidad.
4. Se debe implementar un repositorio de datos geográficos a partir del cual se generen los servicios de visualización y procesamiento.
5. Es necesario realizar un análisis de la infraestructura física requerida para soportar la plataforma. Se deben realizar encuestas y dimensionar de forma detallada y precisa este ítem, ya que es el que más costos involucra. De estas encuestas también pueden surgir nuevos datos candidatos a ser publicados.
6. Se deben analizar los demás sistemas de la universidad, los cuales puedan proveer información relevante que pueda usarse para su publicación. De este análisis se debe elaborar y ejecutar un plan de brechas para lograr tener una arquitectura institucional de referencia en donde los sistemas interactúen de forma transparente.
7. Se debe contemplar el aspecto de la actualización de los datos, lo que incurre en la actualización de los metadatos presentados al público, para ofrecer siempre información actualizada y veraz.
8. Deben definirse las políticas de acceso a la plataforma a los estudiantes y docentes, control sobre que se publica. Debiera aprovecharse el ambiente colaborativo para mostrar la investigación que realiza la universidad Distrital.
147
9. Se recomienda desarrollar los servicios web no cubiertos en este proyecto de investigación en la Infraestructura de Datos Espaciales CECAD, esto con el fin de dar cumplimiento a todas las recomendaciones planteadas por el OGC, para la implementación de geoservicios web geográficos.
5.2 CONCLUSIONES
Es difícil ofrecer una conclusión acerca de las posibilidades de un trabajo o línea de investigación a la que aún le queda mucho camino por delante, sin embargo:
1. El modelo propuesto adopta una estructura flexible y modular proveyendo un mecanismo como alternativa de despliegue de aplicaciones web Móvil con componente GeoEspacial en GIS Mobile Cloud Computing de una manera eficiente para desplegar y generar valor a la información espacial y extender de esta manera, el concepto de servicios web geoespaciales en el campo de las comunicaciones móviles y, aportando a la necesidad de una Infraestructura de Datos Espaciales en primera instancia a nivel local. Es evidente entonces que, el modelo desarrollado e implementado aporta una Infraestructura de Datos Espaciales habilitada para la Cloud basada en una arquitectura orientada a servicios web y habilitada para Mobile Cloud Computing.
2. De acuerdo o con base en todas las tecnologías que posibilitan la implementación de una Infraestructura de Datos Espaciales habilitada para la Mobile Cloud Computing (MCC), la clave fue implementar un modelo (NODO Geo-espacial) de accesibilidad a servicios web geográficos, de manera que en los clientes móviles se logra implementar la manera de consumir los servicios web de Geo-procesamiento desde la Infraestructura de Datos Espaciales planteada habilitada para la Cloud.
3. Aunque la implementación (Modelo propuesto) fue probada sobre un ambiente experimental, la investigación mostró que esta es una buena alternativa para el despliegue de Servicios Web Geo-espaciales Mobile Cloud. Para ello, se debe adoptar oficialmente interfaces estándar OGC para el geo-procesamiento de servicios web basados en Mobile Cloud Computing (MCC).
148
4. El presente trabajo de investigación, describe los componentes básicos que definen el Modelo de Accesibilidad Móvil a Servicios de Información Geográfico en la Nube Computacional traducido en un modelo que prepara el camino en la investigación para las ciencias de la tierra en nuestro entorno y, permitirá a toda la comunidad estudiantil acceder a una plataforma computacional accesible y pre-configurada, fácil de emplear para realizar geo-procesamiento de grandes volúmenes de información (Big Spatial Data) aprovechando los beneficios de una nueva infraestructura de IT en la academia, la cual incluye el balanceo de geo-procesos, la administración de los recursos y el despliegue de aplicaciones móviles en la Cloud Computing.
5. El presente trabajo de investigación reúne en un solo modelo conceptual las recomendaciones que a la fecha existen y, que propone el Open Geospatial Consortium (OGC) para servicios web de notificación y registro de información geográfica en la web; con esto se logra dar un paso con el fin de apropiar desde los Sistemas de Información Geográfico, las Tecnologías de la Información y la Comunicación (TIC) en Colombia acortando la brecha tecnologica que existe en nuestro entorno.
6 El modelo propuesto adopta el paradigma Mobile Cloud Computing, integra Cloud Computing en un ambiente móvil basado en IDE con el objeto de sobreponerse a obstáculos técnicos inherentes a los dispositivos móviles como son: la duración de la batería, la latencia, el ancho de banda y el almacenamiento en los dispositivos móviles en ambientes escalables y heterogéneos.
7 Del presente trabajo de investigación se desprende que, el uso de Cloudlets en el modelo propuesto tiene gran beneficio; el modelo permite la transferencia de datos (telemática) de manera rápida, ágil procesamiento de las aplicaciones, menos uso de recursos en los dispositivos móviles; se deduce que. sin el uso de Cloudlets, el procesamiento es llevado de manera directa a grandes Clouds distantes de manera que el tiempo en la comunicación y el procesamiento es mucho mayor, además, la vida de la batería en los dispositivos móviles se reduce, el uso de la memoria de los dispositivos móviles es alto, todo esto en definitiva es, lo que molesta a los usuarios de tecnologia móvil.
149
BIBLIOGRAFÍA
[1] Comisión de Regulación de Comunicaciones (CRC) – República de Colombia 2010, Análisis del sector TIC en Colombia: Evolución y Desafíos; Documento de Análisis Regulación de Infraestructura y Centro de Conocimiento de la Industria (pp. 1-75). Colombia. [2] T. Verbelen, P. Simoens, F. De Turck, and B. Dhoedt, “Cloudlets: Bringing the cloud to the mobile user,” in Proceedings of the third ACM workshop on Mobile cloud computing and services. ACM, 2012, pp. 29–36. [3] Nah, F., 2004. A study on tolerable waiting time: how long are Web users willing to wait? Behavior & Information Technology, �23 (3), 153 163. [4] E. Cuervo, A. Balasubramanian, D.-k. Cho, A. Wolman, S. Saroiu, R. Chandra, and P. Bahl, “Maui: making smartphones last longer with code offload,” in Proceedings of the 8th international conference on Mobile systems, applications, and services. ACM, 2010, pp. 49–62. [5] M. Demirbas and H. Ferhatosmanoglu. Peer-to-peer spatial queries in sensor networks. In Proc. of P2P, 2003. [6] Plaza, A.J. and Chang, C.I., 2008. High performance computing in remote sensing. Gainesville, USA: CRC Press. [7] D. Peuquet. Making space for time: Issues in space-time data representation. GeoInform., 5:11–32, 2001. [8] Hey, T., Tansley, S., and Tolle, K., 2009. The fourth paradigm: data-intensive scientific discovery [online]. Microsoft Research, Redmond, WA. Available from: http://research.microsoft. com/en-us/collaboration/fourthparadigm/ [Accedido 3 Diciembre 2012]. [9] Principles of XML design: Element structures for names and addresses. Disponible en: http://www.ibm.com/developerworks/xml/library/x-elemdes.html [10] XML Schema Part 2: Datatypes, Biron, P. V., Malhotra, A. (Editors) World Wide Web Consortium Recommendation, 2 May 2001. Disponible en: http://www.w3.org/TR/xmlschema-2/ [11] Gonzalez, H., et al., 2010. Google fusion tables: data management, integration and collaboration in the cloud. In: Proceedings of the 1st ACM Symposium on
�Cloud Computing, SoCC’10, 6 11 June 2010, UC Berkeley, Berkeley, CA, USA. �New York: ACM, 175 180.
150
[12] J. Schiller and A. Voisard. Location-Based Services. Morgan Kaufmann, 2004. [13] V. Sacramento, M. Endler, H. Rubinsztejn, L. Lima, K. Goncalves, F. Nascimento, and G. Bueno. Moca: A middleware for developing collaborative applications for mobile users. Dist. Sys. Online, IEEE, 5(10):1–14, 2004. [14] M. Menzel and R. Ranjan, “Cloudgenius: decision support for web server cloud migration,” in Proceedings of the 21st international conference on World Wide Web. ACM, 2012, pp. 979–988. [15] I. Satoh. Dynamic deployment of pervasive services. In Proc. of ICPS, 2005. [16] S. Garg, S. Versteeg, and R. Buyya, “Smicloud: A framework for comparing and ranking cloud services,” in Utility and Cloud Computing (UCC), 2011 Fourth IEEE International Conference on. IEEE, 2011, pp. 210–218. [17] R. Mayrhofer, C. Holzmann, and R. Koprivec. Friends radar: Towards a private P2P location sharing platform. In Proc. of EUROCAST. 2012. [18] G. Huerta-Canepa and D. Lee. A virtual cloud computing provider for mobile devices. In Proc. of MCS, 2010. [19] XML y la gestión de contenidos" [en línea]. Hipertext.net. 2005, núm. 3. Disponible en Web: http://www.hipertext.net/web/pag256.htm >. ISSN: 1695-5498 [20] National Institute of Standards and Technology (NIST) Definition of Cloud Computing (Draft) [en línea]. Disponible en Web: http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf [21] National Institute of Standards and Technology (NIST) Cloud Computing Efforts May 20, 2010 [en línea]. Disponible en Web: http://csrc.nist.gov/groups/SNS/cloud-computing/documents/forumworkshop-may2010/nist_cloud_computing_forum-leaf.pdf [22] Verdugo, H., Lucero, C., & Veras, A. (2009). COMPUTACION EN LA NUBE. Universidad Tecnica Federico Santa Maria. [23] Nimbus: Cloud Computing for Science, Keahey, K. HPAGC 2011. Chicago, IL. April 2011. (pptx) [24] Nebula Cloud Computing Platform - NASA, http://nebula.nasa.gov/
151
[25] VMWare ESX Server, www.vmware.com/products/esx [26] Amazon Elastic Computing Cloud, aws.amazon.com/ec2 [27] B. Y. Zhao, J. D. Kubiatowicz, and A. D. Joseph. Tapestry: An infrastructure for fault-tolerant wide-area location and routing. Technical report, University of California at Berkeley, Berkeley, CA, USA, 2001. [28] Hadoop MapReduce, hadoop.apache.org/mapreduce [29] Cloud Hosting, CLoud Computing and Hybrid Infrastructure from GoGrid, http://www.gogrid.com [30] ESRI: http://www.esri.com/what-is-gis/index.html [31] GIS: http://www.whatisgis.com/whatisgis.htm [32] ArcGIS Server: http://www.esrichile.com/productos_detalle.php?cod=454545&cat=20&subcat=18 [33] Servicios Web (Web Services): http://www.w3c.es/divulgacion/guiasbreves/ServiciosWeb [34] S.O.A. Principles: http://soaprinciples.com/p2_esp.php [35] WSDL: http://www.service-architecture.com/web services/articles/web_services_explained.html [36] WSDL: http://www.w3.org/TR/wsdl [37] http://www.opengeospatial.org/standards/ [38] http://live.osgeo.org/es/overview/geoserver_overview.html [39] http://es.wikipedia.org/wiki/Telefon%C3%ADa_m%C3%B3vil [40] http://www.itc.nl/library/Papers_2007/msc/gfm/delikostidis.pdf [41] http://developers.sun.com/mobility/midp/articles/ota/ [42] Environmental Informatics Archives, Volume 2 (2004), 920-926 [43] http://www.theserverlabs.com/es/cloud-computing.html
152
[44] http://www.ibm.com/developerworks/cloud/library/cl-mobilecloudcomputing/ [45] http://www.opennebula.org/documentation:uc4 [46] SARAVIA, MIGUEL (2003) “Ideas para repensar la Conectividad en Áreas Rurales” Intermediate Technology Development Group Marzo, 2003. Disponible en línea:[http://ebookbrowse.com/ideas-para-repensar-la-conectividad-en-areas-rurales-pdf-d59789946] [47] Vikas Kottari#1, Vishwanath Kamath G#2, Lloyd Presley Saldanha#3, Chandan Mohan#4: A Survey on Mobile Cloud Computing: Concept, Applications and Challenges. In: Computer Science and Engineering, Canara Engineering College, Mangalore, India Computer Science and Engineering, Canara Engineering College, Mangalore, India 2 (2013) Nr. 3, S. 1-6 [48] Cloud Computing definition http://www.techterms.com/definition/cloud_computing [49] Saurabh Kumar Garg a, *, Steve Versteeg b, Rajkumar Buyyaa: Future Generation Computer Systems. In: Review of Economic Studies 1 (2012) Nr. 1, S. 1-8 [50] B. Rochwerger, D. Breitgand, E. Levy, A. Galis, K. Nagin, I. Llorente, R. Montero, Y. Wolfsthal, E. Elmroth, J. Ca´ceres et al., “The reservoir model and architecture for open federated cloud computing,” IBM Journal of Research and Development, vol. 53, no.4, pp. 1–11, 2009. [51] M. Cusumano, Cloud computing and SaaS as new computing platforms, Communications of the ACM 53 (4) (2010) 27–29. [52] R. Buyya, C. Yeo, S. Venugopal, J. Broberg, I. Brandic, Cloud computing and emerging IT platforms: vision, hype, and reality for delivering computing as the 5th utility, Future Generation Computer Systems 25 (6) (2009) 599–616. [53] E. Ciurana, Developing with Google App Engine, Apress, Berkeley, CA, USA, 2009 [54] J. Varia, Best practices in architecting cloud applications in the AWS cloud, in: Cloud Computing: Principles and Paradigms, Wiley Press, 2011, pp. 459–490. (Chapter 18). [55] Cloud Service Measurement Index Consortium (CSMIC), SMI framework. URL: http://beta-www.cloudcommons.com/servicemeasurementindex.
153
[56] J. Cochrane, M. Zeleny, Multiple Criteria Decision Making, Univ. of South Carolina Pr., 1973. [57] R. Calheiros, C. Vecchiola, D. Karunamoorthy, R. Buyya, The Aneka platform and QoS-driven resource provisioning for elastic applications on hybrid Clouds, Future Generation Computer Systems 28 (6) (2011) 861–870. [58] Brooks, C., et al., 2004. The Massive User Modelling System (MUMS). Intelligent Tutoring Systems: Lecture Notes in Computer Science, 3220 (2004), �73 112.
[59] Su, D., et al., 2010. Research of spatial decision support system construction based on cloud model. In: Proceedings of 2010 International Conference on E-Business and E- �Government (ICEE 2010), 7 9 May 2010, Guangzhou, China,
�IEEE, 691 694. [60] Mobilia, S., et al., 2009. Sustainability on-orbit: space solar power and cloud computing constellation two examples of international offset projects. In: Proceedings of 60th International Astronautical Congress 2009, IAC 2009,
� �8:6141 6147, 12 16 October 2009, Daejeon, Republic of Korea, Curran �Associates Inc., 6141 6147.
[61] Cui, D., Wu, Y., and Zhang, Q., 2010. Massive spatial data processing model based on cloud computing model. In: Proceedings of the Third International Joint Conference on Computational Sciences and Optimization, IEEE Computer Society,
� �Los Alamitos, CA, 28 31 May 2010, Huangshan, Anhui, China, IEEE, 347 350. [62] Yang C., et al., 2011b. Using spatial principles to optimize distributed computing for enabling physical science discoveries. Proceedings of National
�Academy of Sciences, 106 (14), 5498 5503. doi: 10.1073/pnas.0909315108. [63] Mell, P. and Grance, T., 2009. The NIST definition of cloud computing Ver. 15. [online]. NIST.gov. Available from: http://csrc.nist.gov/groups/SNS/cloud-computing/ [Accedido 5 Octubre 2012]. [64] Lee, Y. and Chen, K., 2010. Is server consolidation beneficial to MMORPG? A case study of world of warcraft. In: Proceedings of 2010 IEEE 3rd international
� �conference on cloud computing, CLOUD 2010, 5 10 July 2010, 435 442.
154
[65] Bernstein, Q.T., Vidovic, N., and Modi, S., 2010. A cloud PAAS for high scale,
�function, and velocity mobile applications with reference application as the fully connected car. In: Proceedings of the 2010 Fifth International Conference on Systems and Networks Communications (ICSNC’10). Washington, DC, USA: IEEE
�Computer Society, 117 123. doi: 10.1109/ICSNC.2010.24. Available from: http://dx.doi.org/10.1109/ICSNC.2010.24 [Accedido 2 Enero 2011]. [66] Olson, A.J., 2010. Data as a service: Are we in the clouds? Journal of Map &
�Geography Libraries, 6 (1), 76 78. [67] Jiang, J.R., 2011. Nondominated local coteries for resource allocation in grids
�and clouds. Information Processing Letters, 111, 379 384.
�[68] Marston, S., et al., 2011. Cloud computing the business perspective. �Decision Support Systems, 51, 176 189.
[68] Chappell, D., 2008. Introducing the azure services platform. Microsoft Corporation document. Available from: http://www.davidchappell.com/writing/white_papers/Introducing_Windows_Azure_v1-Chappell.pdf [Accedido 7 Marzo 2012]. [69] W. Vogels, A head in the clouds the power of infrastructure as a service,in: Proceedings of the 1st Workshop on Cloud Computing and Applications,CCA’08. [70] K. Kumar, Y.-H. Lu, Cloud computing for mobile users: can offloading computation save energy? Computer 43 (2010) 51–56. [71] E.E. Marinelli, Hyrax: cloud computing on mobile devices using MapReduce, Masters Thesis, Carnegie Mellon University, 2009. [72] M. Satyanarayanan, P. Bahl, R. Caceres, N. Davies, The case for VM-based cloudlets in mobile computing, IEEE Pervasive Computing 8 (2009) 14–23. [73] Niroshinie Fernando *, Seng W. Loke *, Wenny Rahayu: Mobile cloud computing: A survey. In: The Quarterly Journal of Economics (2013) Nr. 29, S. 84-106 [74] Tim Verbelen , Tim Stevens , Filip De Turck , Bart Dhoedt, Graph partitioning algorithms for optimizing software deployment in mobile cloud computing, Future Generation Computer Systems, v.29 n.2, p.451-459, February, 2013 [75] X. Wu, S. Tavildar, S. Shakkottai, T. Richardson, J. Li, R. Laroia, and A. Jovicic. FlashLinQ: A synchronous distributed scheduler for peer-topeer ad hoc networks. In Proc. of Allerton, 2010.
155
[76] D. H. Le Xu, Vijayakrishnan Nagarajan and W.-T. Tsai, “Secure Web Referral Services for Mobile Cloud Computing,” in IEEE International Symposium on Mobile Cloud, Computing, and Service Engineering (IEEE MobileCloud), 2013. [77] N. Banerjee, S. Agarwal, P. Bahl, R. Chandra, A. Wolman, and M. Corner. Virtual compass: Relative positioning to sense mobile social interactions. In Proc. of Pervasive. 2010. [78] [Online] http://www.mobilecloudcomputingforum.com/ Last Accessed January 2014. [79] Dinh Hoang T., Lee Chonho, Niyato Dusit , and Ping Wang Dusit, \A survey of mobile cloud computing: architecture, applications, and approaches." Wireless Communications and Mobile Computing 2011. Volume 13, Issue 18, pages 1587-1611 [80] T. Sivasakthi and Dr. N. Prabakaran, (2014), Applying Digital Signature with Encryption Algorithm of User Authentication for Data Security in Cloud Computing, International Journal of Innovative Research in Computer and Communication Engineering, Vol. 2, Issue 2, pp. 456-459. [81] N Hemalatha, A Jenis, Cecil A Donald and L Arockiam (2014), A Comparative Analysis of Encryption Techniques and Data Security Issues in Cloud Computing, International Journal of Computer Applications, 96(16):1-6. [82] Daniela Popa, Marcel Cremene, Monika Borda, Karima Boudaoud (2013) , A Security Framework for Mobile Cloud Applications, published in IEEE 11th Roedunet International Conference, pp. 1-4 [83] Fieldin, Roy Thomas. "Architectural Styles and the Design of Network-based Software Architectures". Doctoral dissertation in Information and Computer Science, University of California, Irvine, 2000. [84] A. Ziotopoulos and G. de Veciana. P2P network for storage and query of a spatio-temporal flow of events. In Proc. of PerCom Workshops, 2011. [85] Rellermeyer Jan S., Riva Oriana, and Alonso Gustavo, "AlfredO: an architecture for Flexible interaction with electronic devices." In Proceedings of the 9th ACM/IFIP/USENIX International Conference on Middleware, pp. 22-41. Springer-Verlag New York, Inc., 2008.
156
[86] Zhang Xinwen, Schiman Joshua, Gibbs Simon, Kunjithapatham Anugeetha, and Jeong Sangoh, "Securing elastic applications on mobile devices for cloud computing." In Proceedings of the 2009 ACM workshop on Cloud computing security, 2009. pp. 127-134. [87] Das Tathagata, Mohan Prashanth, Padmanabhan Venkata N., Ramjee Ramachandran , and Sharma Asankhaya, \PRISM: platform for remote sensing using smartphones." In ACM Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services, 2010., pp. 63-76. [88] Goyal, Sachin and Carter, John, "A lightweight secure cyber foraging infrastructure for resource-onstrained devices." In Sixth IEEE Workshop on Mobile Computing Systems and Applications. WMCSA 2004. , pp. 186-195. [89] Chun Byung-Gon, and Maniatis Petros, "Augmented Smartphone Applications Through Clone Cloud Execution." In HotOS 2009, vol. 9, pp. 8-11. [90] Naif Aljabri, Fathy Essa, “Scheduling Manager for Mobile Cloud Using Multi-Agents”, International Journal of Computer and Information Technology, 2013. [91] A. Guttman. R-trees: a dynamic index structure for spatial searching. In Proc. of SIGMOD, 1984. [92] G. Castelli, M. Mamei, and F. Zambonelli. The changing role of pervasive middleware: From discovery and orchestration to recommendation and planning. In PerWare Workshop at the 9th IEEE International Conference on Pervasive Computing and Communications, Seattle (WAS), pages 214{219, March 2011. [93] Giurgiu Ioana, Riva Oriana, Juric Dejan , Krivulev Ivan, and Alonso Gustavo, "Calling the cloud: enabling mobile phones as interfaces to cloud applications." In Proceedings of Middleware 2009, pp. 83-102. Springer Berlin Heidelberg, 2009. [94] Wu Jie, and Li Hailan, "On calculating connected dominating set for efficientrouting in ad hoc wireless networks." In Proceedings of the 3rd ACM International Workshop on Discrete Algorithms and Methods for Mobile Computing and communications, 1999, pp. 7-14. [95] Blum, J., Ding, M., Thaeler, A., and Cheng, X. (2004), Handbook of combinatorial optimization, Kluwer Academic Publishers, Netherlands. [96] � �M.S. Corson and A Ephremides A Distributed Routing Algorithm for Mobile
�Wireless Networks ACM J. Wireless Networks. 1(1). Jan. 1995
157
[97] Xu Ya, Heidemann John, and Estrin Deborah, \Geography-informed energy conservation for ad hoc routing." In Proceedings of the 7th ACM Annual International Conference on Mobile Computing and Networking 2001., pp. 70-84. [98] Miada Al-masre, Fathy Alburi. "Manager Architecture for Mobile Cloud Computing-Cloudlet based". Asian Journal of Computer and Information Systems (ISSN: 2321 – 5658) Volume 02 – Issue 01, February 2014 [99] OpenGIS™ Abstract Specification, OpenGIS™ Project Documents 99-100 through 99-116, Disponible en: <http://www.opengis.org/techno/specs.htm>. [100] Leal, B., & Atzori, L. (2012). Modeling and performance evaluation of MANET handover. Ph.D. Thesis, Simon Bolivar University, Venezuela. [101] Micus (2004) The market for geospatial information - potentials for employment, innovation and value added. [Online]. Disponible: http://www.micus.de/pdf/micus_geoinfo_germany.pdf [102] Hartig K (2008) What is Cloud Computing? The cloud is a virtualization of resources that maintains and manages itself. .In: NET Developers Journal, SYS-CON Media. [103] Leal, B., & Atzori, L. (2012). Modeling and performance evaluation of MANET handover. Ph.D. Thesis, Simon Bolivar University, Venezuela.
158
ANEXO A
SERVICIOS WEB GEOGRAFICOS IMPLEMENTADOS. El presente trabajo corresponde a una investigación acerca de la accesibilidad móvil a servicios web de información geográfica en la nube computacional, investigación que se expresa en términos de un modelo orientado a servicios (Service-Oriented Architecture -SOA), propuesto y basado en el concepto de una Infraestructura de Datos Espaciales (IDE), adoptando el concepto básico de un proveedor de servicio, un consumidor de servicios y un catálogo de servicios web geográficos. Para tal fin, la investigación se soporta en estándares del OGC (Open Geospatial Consortium) para servicios web de información vectorial y tipo ráster. El comité técnico del OGC ha desarrollado una arquitectura que soporta su visión de tecnología geoespacial e interoperabilidad de datos, a este concepto lo llama, Especificación Abstracta para los Sistemas de Información Geográfico de software libre “OpenGIS Abstract Specification”. Esta especificación provee el fundamento conceptual para la mayor parte de las actividades de desarrollo en la especificación del OGC. 10 El OpenGIS es una marca registrada del OGC, además, este nombre es asociado con la documentación y las especificaciones producidas por el OGC. Los protocolos e interfaces de código abierto están construidas y están referenciadas en esta especificación abstracta además, posibilitan la interoperabilidad entre diferentes marcas y diferentes tipos de sistemas de procesamiento espacial. La especificación abstracta provee un modelo de referencia para el desarrollo de las especificaciones en la implementación del OpenGIS. 10
10
http://www.opengeospatial.org/standards/as Accedido en 13-03-2015).
159
Los estándares del OGC son documentos técnicos que detallan las interfaces y las codificaciones (encodings) del software. Los desarrolladores de software, empelan estos documentos para construir interfaces y código abierto en los productos desarrollados y en los servicios web expuestos. OGC Web Services (OWS), son estándares del OGC creados para emplear en las aplicaciones web (World Wide
Web). Las comunidades de información geográfica (Geographic Information Communities - GIC) requieren de una tecnología que los empodere y divulgue su existencia y la existencia de su información, de tal manera que, otros individuos que no pertenecen al GIC los puedan descubrir y decidan si desean o no compartir su información. [37] En el amplio contexto de los servicios web, OGC Web Services (OWS) representa un evolucionado marco de referencia basado en estándares, los cuales posibilitan la integración de una gran variedad de servicios online de localización y Geoprocesamiento. Esta integración de sistemas de Geoprocesamiento distribuido permite comunicar a unos con otros a través de la web empleando tecnologías comunes como XML y HTTP. [99]
Figura 53. OGC Web Services (OWS)
Fuente: Open Geospatial Consortium - OGC
160
El catálogo de servicios del OGC es la herramienta fundamental para el descubrimiento de información geoespacial digital. Tal como las librerías tradicionales, el OGC postula que el catálogo de servicios es la puerta de entrada “gateway” a través de la cual los usuarios pueden encontrar los requerimientos de información del grupo más cercano de información apropiada y disponible. [99]
Figura 54. Catálogos en la librería mundial
Fuente: Open Geospatial Consortium - OGC Los catálogos se emplean para organizar y navegar la información geográfica (geodata) de mayor interés. Para lograr este objetivo, se debe apalancar la información disponible como metadatos. Los catálogos se emplean principalmente para la búsqueda de elementos empleando palabras claves en los metadatos y en sus valores asociados; se emplean también para encontrar el flujo de trabajo de un geoproceso en particular; para consultar la aptitud de la información acerca de la geodata para una aplicación en particular, para consultar si existe o no cierta información requerida y, para posibilitar diferentes perfiles o vistas del mismo conjunto de datos (geodata). [99]
161
A.1 RECURSOS GEOESPACIALES (GEORECURSOS) Los catálogos del OpenGIS pueden ser empleados para el descubrimiento tanto de geodata como para el descubrimiento de geoservicios. El término “Georecurso” se emplea para representar y abarcar ambos conceptos. Un recurso geoespacial es la unidad básica (abstracta) de información geoespacial en un ambiente de sistemas de computación en red. Un recurso geoespacial también representa al primer objeto que manipula una aplicación de software geoespacial. [37]
Figura 55. Recursos Geoespaciales
Fuente: Open Geospatial Consortium - OGC
162
En la sección 2.1 y en la sección 3.5.2.2 del presente trabajo de investigación, se describen los servicios web geográficos acá empleados, sin embargo, en esta sección de anexos, se ampliara la conceptualización desde el punto de vista OGC (Open Geospatial Consortium). A.2. ESPECIFICACIÓN DE LA IMPLEMENTACIÓN OGC Web Services (OWS) es un proveedor neutral, proporciona un marco de referencia interoperable de recursos de geoinformación en línea (online), con el objetivo de acceder a los datos, al descubrimiento de información en la web, al análisis de información, a la integración y a la visualización de múltiples georecursos con capacidades de geoprocesamiento. A continuación se relaciona una breve lista de las especificaciones de implementación (descritos en la sección 2.1 y sección 3.5.2.2) más importantes en relación con el mapeo en la web (Web Mapping) y que se adoptan como referencia para el presente trabajo de investigación.
• Filter Encoding (Filter) • Geography Markup Language (GML) • Simple Features (SFO, SFS, SFC) • Styled Layer Descriptor (SLD) • Web Coverage Service (WCS) • Web Feature Service (WFS) • Web Map Context Documents (WMC) • Web Map Service (WMS)
La familia de servicios web de la OGC (OGC Web Services - OWS) incluye dentro de sus estándares y en particular dentro de la lista anterior, tres (3) tipos de mayor relevancia para sus servicios web con el fin de acceder a la información georeferenciada: Web Map Server (WMS), Web Coverage Server (WCS), y Web
Feature Server (WFS); adicionalmente a estos servicios, existen los servicios de GeoParser y GeoCoder los cuales retornan resultados referenciados espacialmente. [99]
163
A.2.1 Web Map Service (WMS)
Como se describió con anterioridad (sección 2.1 y sección 3.5.2.2), un Servicio de Mapas Web (Web Map Service - WMS) es un estándar para proveer visualización de datos geoespaciales en internet. Es decir, el WMS permite consumir información de un mapa en internet o publicar capas (layers) de mapa desde un Sistema de Información Geográfico o simplemente posibilita procesar una imagen en la web. [99]
A.2.1.1. Que es un Web Map Service (WMS)
El Web Map Service (WMS) proporciona acceso de manera uniforme a los clientes web a los mapas desplegados en internet por los servidores de mapas. De acuerdo con [99]:
- WMS posibilita dinámicamente la construcción de un mapa como si fuese una imagen, es decir, como una serie de elementos gráficos o como un conjunto de elementos de información geográfica.
- WMS posibilita poder responder a consultas básicas en relación con el
contenido de cierto mapa.
- WMS puede informar o alertar a otros programas, los mapas que se pueden producir o elaborar y cuales mapas se pueden emplear de consulta adicional.
En términos generales, el WMS soporta la creación y el despliegue de mapas registrados o superpuestos que provengan de múltiples fuentes de información, fuentes remotas o fuentes heterogéneas. El resultado del WMS es una imagen tipo ráster lista para desplegar. [99]
164
A.2.1.2. Cómo Funciona el Web Map Service (WMS)
Una vez implementado el WMS tanto por un software cliente como por un software servidor, cualquier cliente puede acceder a cualquier mapa en cualquier servidor. En otras palabras, el software cliente podrá combinar mapas desde uno o más servidores. Así mismo, cualquier software cliente podrá consultar información de un mapa provisto por cualquier software servidor. Mientras que los programadores o desarrolladores escriben código para realizar la implementación de las especificaciones, los usuarios finales solo deberán publicar y acceder la información espaical que incluya el estándar y, los compradores de software podrán elegir la mejor solución sin preocuparse si esta es compatible con otras soluciones mientras todos implementen el mismo estándar WMS. [37]
Figura 56. Funcionamiento del WMS
Fuente: Open Geospatial Consortium - OGC
165
El Web Map Service (WMS) define las siguientes operaciones: [99] 1. Como adquirir y proveer información acerca de los tipos de mapas que un servidor puede entregar. (GetCapabilities) 2. Como solicitar y proveer un mapa como una imagen o como un conjunto de elementos. (GetMap) 3. Como solicitar y proveer información acerca del contenido de un mapa, contenido como el valor de un elemento en particular o su localización. (GetFeatureInfo) 4. El archivo GetCapabilities reside en el servidor y por tanto una solicitud GetCapabilities acaba en el servidor web y, este deberá enviar el archivo de nuevo al usuario final. De otro lado, las operación GetMap solicita preguntar datos almacenados en la Base de Datos por consiguiente el servidor web deberá conectarse a la Base de Datos y extraer la información solicitada. La siguiente figura, muestra cual es el alcance de las solicitudes GetCapabilities y GetMap.
Figura 57. Solicitudes GetCapabilities y GetMap
Fuente: Open Geospatial Consortium - OGC
166
A.2.2. Web Feature Service (WFS)
El Servicio de Elementos Web (Web Feature Service - WFS) define las operaciones para manipular la información de elementos geográficos en las primitivas básicas de puntos, líneas y polígonos. Estas operaciones permiten ejecutar transacciones (consulta, creación, actualización o borrado) sobre los datos espaciales a través de la web. La descripción de las geometrías de los elementos geográficos en la especificación Web Feature Service (WFS) esta codificado en Geography Markup Language (GML). [99]
A.2.2.1. Que es un Web Feature Service (WFS)
El Servicio de Elementos Web (Web Feature Service - WFS) es una interface que posibilita realizar la solicitud de elementos geográficos a través de internet empleando llamados en plataformas independientes en forma de URLs. Considere a los elementos geográficos como el “código fuente” detrás de un mapa, en donde la interface WMS únicamente retorna una imagen la cual no puede ser empleada para edición o análisis. La especificación WFS define una interface que describen las operaciones para la manipulación de los datos de los elementos geográficos. Las operaciones para la manipulación de los datos, incluye la habilidad para: [99] 1. Consultar o adquirir elementos con base en restricciones espaciales y no-espaciales. 2. Crear una nueva instancia de un elemento. 3. Borrar una instancia de algún elemento. 4. Actualizar la instancia de algún elemento.
167
A.2.2.2. Cómo Funciona el Web Feature Service (WFS)
Una petición WFS consiste en una descripción de las operaciones de consulta y transformación de datos a aplicar. La petición (Request) es generada en el cliente y publicada en un servidor WFS. El servidor WFS lee y ejecuta la petición devolviendo el resultado en un conjunto de elementos codificados en formato GML. De esta forma, un cliente que implemente GML podrá emplear este conjunto de elementos. [99]
Figura 58. Funcionamiento del WFS
Fuente: Open Geospatial Consortium - OGC A manera de resumen, el WFS define las siguientes operaciones:
GetCapabilities (obligatorio) DescribeFeatureType (obligatorio) GetGmlObject (opcional) GetFeature (obligatorio) Transaction (opcional) LockFeature (opcional)
168
A.2.3. Web Processing Service (WPS)
Un Servicio de Procesamiento Web (Web Processing Service - WPS) provee acceso a los clientes a través de la red a cálculos pre-programados y a modelos computacionales que opera sobre datos espacialmente referenciados. Los cálculos pueden ser muy simples o extremadamente complejos con cualquier cantidad de datos de entrada y de salida. [99] El presente trabajo de investigación no entra en detalle acerca del proceso específico que se implementa en una instancia de un WPS, únicamente describe el mecanismo genérico que puede emplearse para referir y posibilitar vía web cualquier tipo de proceso geoespacial. El presente apartado del trabajo de investigación, no conduce al descubrimiento, catalogación, recuperación de información que se crea cuando se ejecuta un WPS. [99]
A.2.3.1. Cómo Funciona el Web Processing Service (WPS)
La interface del Servicio de Procesamiento Web (Web Processing Service - WPS) especifica tres (3) operaciones que pueden ser requeridas por un cliente y ejecutadas por un servidor WPS, operaciones todas obligatorias de implementar por todos los servidores. Estas operaciones son: [99] a) GetCapabilities: esta operación permite a los clientes solicitar y recibir los metadatos de un servicio (Capabilities) y los documentos que describen las habilidades acerca de la implementación de un servidor en particular. La operación GetCapabilities provee el nombre y la descripción general de cada uno de los procesos que ofrece una instancia de un WPS. Esta operación también soporta la negociación de la versión en la especificación empleada por las interacciones cliente-servidor. b) DescribeProcess: esta operación permite a los clientes solicitar y recibir información detallada acerca de los procesos que pueden ejecutarse en la instancia de un servidor incluyendo las entradas requeridas, los formatos permitidos y, las salidas que que podrían producirse.
169
c) Execute: esta operación permite a un cliente ejecutar procesos específicos que han sido implementados en un WPS, empleando para ello valores de parámetros que han sido introducidos retornando las salidas que se han generado. De manera general, el documento respuesta es retornado solamente cuando el proceso ejecutado ha sido completado; sin embargo, un cliente puede indicarle al servidor que retorne el documento con la respuesta de la ejecución inmediatamente después que ha sido aceptada por el servidor. Para este caso en particular, la respuesta de la ejecución incluye una URL desde la cual el documento respuesta será retornando más tarde una vez se haya completado la ejecución del proceso. A continuación se muestra en un ejemplo, cómo funciona un WPS por medio de un diagrama de actividad UML: [99]
Figura 59. Diagrama de actividad cuando el cliente solicita almacenar resultados
Fuente: Open Geospatial Consortium - OGC
170
El modelo UML de la interface WPS esta organizado en cuatro (4) paquetes (en términos de ingeniería de software), tal y como se ilustra en la siguiente figura de diagrama de paquetes: [99]
Figura 60. Diagrama de paquetes para la interface WPS
WPS Service+ ProcessBrief
+ WPSDescription+ WPSRequestBase {Abstract}
+ WPService
WPS Get Capabilities+ ProcessOfferings
+ Section+ WPSGetCapabilities
WPS Describe Process+ DescribeProcess+ InputDescription+ InputFormChoice
+ LiteralInput+ LiteralOutput
+ LiteralValuesChoice+ OutputDescription+ OutputFormChoice+ ProcessDescription+ ProcessDescriptions
+ ProcessInputs+ ProcessOutputs+ SupportedCRSs
+ SupportedComplexData+ SupportedEncodings+ SupportedFormats+ SupportedSchemas
+ SupportedUOMs
WPS Execute+ ComplexValue
+ ComplexValueEncoding+ DataInputs+ Execute
+ ExecuteResponse+ IOValue
+ LiteralValue+ OutputDefinition+ OutputDefinitions
+ ProcessFailed+ ProcessOutputs+ ProcessStarted
+ Status+ ValueFormChoice+ ValueReference
OWS Domain(from OWS Common Packages)
+ AllowedValues+ AnyValue+ DataType+ Domain
+ DomainMetadata+ Meaning
+ Metadata {Abstract}+ NoValues
+ PossibleValues+ Range
+ RangeClosure+ ReferenceSystem
+ UOM+ UnNamedDomain+ ValuesReference
+ ValuesUnit
OWS Common(from OWS Common Packages)
+ BoundingBox+ Metadata {Abstract)
+ WGS84BoundingBox
OWS Get Capabilites(from OWS Common Packages)
+ GetCapabilities {Abstract}+ OGCWebService {Abstract}
+ RequestBase {Abstract}+ ServiceMetadata {Abstract}
ISO 19115 Subset(from Logical View)
+ Code
Fuente: Open Geospatial Consortium - OGC
171
Paquete de Servicio WPS: este se ilustra por medio del siguiente diagrama de clases; esta figura no muestra las clases empleadas por las operaciones de Request/Response del WPS, están se muestran en los paquetes de GetCapabilities. Solo se describe el proceso y ejecución del paquete. [99]
Figura 61. Diagrama de clases paquete del servicio WPS
OGCWebService {Abstract}
+ getCapabilities(request : GetCapabilities) : ServiceMetadata
(from OWS Get Capabil ites)
<<Interface>>
Each server instance instantiates only one object of this class, and this object always exists while server is available.
WPService
+ describeProcess(request : DescribeProcess) : ProcessDescriptions+ execute(request : Execute) : ExecuteResponse
RequestBase {Abstract}
+ service : CharacterString+ request : CharacterString+ version : CharacterString
(from OWS Get Capabil ites)
WPSRequestBase {Abstract}
+ service : CharacterString = "WPS" {frozen}
Code
+ code : CharacterString+ codeSpace [0..1] : URI
(from ISO 19115 Subset)
WPSDescription
+ title : CharacterString+ abstract [0..1] : CharacterString
1
1
+identifier 1
1
Metadata {Abstract)
+ metadata [0..1] : Any+ link [0..1] : URL+ about [0..1] : URI
(from OWS Common)
ProcessBrief
+ processVersion [0..1] : CharacterString0..* 0..*
+metadata
0..* 0..*
Fuente: Open Geospatial Consortium - OGC
172
Figura 62. Diagrama de clases paquete GetCapabilities WPS
OGCWebService {Abstract}
+ getCapabilities(request : GetCapabilities) : ServiceMetadata
(from OWS Get Capabil ites)
<<Interface>>
GetCapabilities {Abstract}
+ service : CharacterString+ request : CharacterString = "GetCapabilities" {frozen}+ acceptVersions [0..1] : Sequence<CharacterString>+ sections [0..1] : List<Section>+ acceptFormats [0..1] : Sequence<CharacterString>+ updateSequence [0..1] : CharacterString
(from OWS Get Capabil ites)
ServiceIdentification(from OWS Service Identification)
OperationsMetadata(from OWS Operations Metadata)
ServiceMetadata {Abstract}
+ version : CharacterString+ updateSequence [0..1] : CharacterString
(from OWS Get Capabil ites)
0..1
1
+serviceIdentification 0..1
1
0..1
1
+operationsMetadata 0..1
1
ServiceProvider(from OWS Service Provider)
1
0..1
1
+serviceProvider0..1
WPSGetCapabilities
+ service : CharacterString = "WPS" {frozen}()ProcessBrief
(from WPS Service)
ProcessOfferings
1..*
1
+processBrief 1..*
1Section
+ serviceIdentification+ serviceProvider+ operationsMetadata+ processOfferings+ all
<<CodeList>>
Fuente: Open Geospatial Consortium - OGC
173
Figura 63. Diagrama de clases paquete descriptor del proceso
OGCWebService {Abstract}
+ getCapabilities(request : GetCapabilities) : ServiceMetadata
(from OWS Get Capabil ites)
<<Interface>>
WPService
+ describeProcess(request : DescribeProcess) : ProcessDescriptions+ execute(request : Execute) : ExecuteResponse
(from WPS Service)
RequestBase {Abstract}
+ service : CharacterString+ request : CharacterString+ version : CharacterString
(from OWS Get Capabil ites)
WPSRequestBase {Abstract}
+ service : CharacterString = "WPS" {frozen}(from WPS Service)
ProcessBrief(from WPS Service)
Code(from ISO 19115 Subset)
DescribeProcess
1
1
+identifier1
1
WPSDescription(from WPS Service)
InputFormChoice
+ complexData : SupportedComplexData+ literalData : LiteralInput+ boundingBoxData : SupportedCRSs
<<Union>>
InputDescription
+ minimumOccurs [0..1] : NonNegativeInteger
1
1
+inputFormChoice 1
1
OutputFormChoice
+ complexData : SupportedComplexData+ literalData : LiteralOutput+ boundingBoxData : SupportedCRSs
<<Union>>
OutputDescription
1
1
+outputChoiceForm 1
1
ProcessDescriptions
ProcessInputs
1..*
1
+input 1..*
1
ProcessOutputs
1..*
1
+output1..*
1
ProcessDescription
+ storeSupported [0..1] : Boolean = false+ statusSuppoerted [0..1] : Boolean = false
1..*
1
+processDescription 1..*
1
0..1
1
+processInputs 0..1
1
1
1
+processOutputs1
1
Fuente: Open Geospatial Consortium - OGC
174
A.2.4. Geography Markup Language (GML)
Es una codificación XML para el transporte y el almacenamiento de información geográfica, incluyendo las geometrías y las propiedades de los elementos geográficos. Es un estándar para el intercambio de datos libres, adecuado para la transmisión de pequeños y medianos volúmenes de información. GML se emplea en todas las herramientas XML estándar. [99]
Figura 64. Resultado en entorno real, petición GetMap de un WMS
Fuente: Empresa de Acueducto y Alcantarillado de Bogotá http://www.acueducto.com.co/wascont/sigue-web/visor/base/index.html
175
Figura 65. Diferencia en los resultados de la petición GetMap (WMS) y GetFeature (WFS)
Fuente: Open Geospatial Consortium - OGC
176
ANEXO B
APLICACIÓN REAL SERVICIOS WEB GEOGRAFICOS IMPLEMENTADOS
Figura 66. Directorio REST de servicios geográficos Servidor geográfico GIS1
Figura 67. Directorio REST de servicios geográficos Servidor geográfico GIS2
177
Figura 68. Ejemplo descripcion de los servicios web geográficos empleados
Ejemplo del schema XML empleado en los servicios web geográficos del presenta trabajo de investigación: XML GEOCODE MALLA ACTUAL <?xml version="1.0" encoding="utf-8"?> <definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:e="http://www.esri.com/schemas/ArcGIS/9.3" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://www.esri.com/schemas/ArcGIS/9.3"> <types> <xs:schema targetNamespace="http://www.esri.com/schemas/ArcGIS/9.3" xmlns="http://www.esri.com/schemas/ArcGIS/9.3"> <xs:element name="GetLocatorProperties"> <xs:complexType /> </xs:element> <xs:element name="GetLocatorPropertiesResponse"> <xs:complexType> <xs:sequence> <xs:element name="Props" type="PropertySet" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="GetDefaultInputFieldMapping"> <xs:complexType />
178
</xs:element> <xs:element name="GetDefaultInputFieldMappingResponse"> <xs:complexType> <xs:sequence> <xs:element name="DefaultMapping" type="PropertySet" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="GetResultFields"> <xs:complexType> <xs:sequence> <xs:element name="PropMods" type="PropertySet" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="GetResultFieldsResponse"> <xs:complexType> <xs:sequence> <xs:element name="ResultFieldsInfo" type="Fields" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="GetStandardizedIntersectionFields"> <xs:complexType /> </xs:element> (SEELIMINAN ALGUNAS ETIQUETAS AL AZAR Y A PROPOSITO……) <portType name="GeocodeServerPort"> <documentation>A class that provides geocoding as a service.</documentation> <operation name="GeocodeAddresses"> <documentation>Geocodes a table of addresses.</documentation> <input message="e:GeocodeAddressesIn" /> <output message="e:GeocodeAddressesOut" /> </operation> <operation name="GetResultFields"> <documentation>Fields contained in the geocoding result.</documentation> <input message="e:GetResultFieldsIn" /> <output message="e:GetResultFieldsOut" /> </operation> <operation name="GetAddressFields"> <documentation>Fields needed to geocode a table of addresses.</documentation> <input message="e:GetAddressFieldsIn" /> <output message="e:GetAddressFieldsOut" /> </operation> <operation name="GeocodeAddress"> <documentation>Geocodes a single address (normal or standardized form).</documentation> <input message="e:GeocodeAddressIn" /> <output message="e:GeocodeAddressOut" />
179
</operation> <operation name="GetDefaultInputFieldMapping"> <documentation>Suggested field name mappings for all input fields.</documentation> <input message="e:GetDefaultInputFieldMappingIn" /> <output message="e:GetDefaultInputFieldMappingOut" /> </operation> <operation name="GetCandidateFields"> <documentation>Fields contained in a list of candidates.</documentation> <input message="e:GetCandidateFieldsIn" /> <output message="e:GetCandidateFieldsOut" /> </operation> <operation name="GetIntersectionCandidateFields"> <documentation>Fields contained by intersection candidates.</documentation> <input message="e:GetIntersectionCandidateFieldsIn" /> <output message="e:GetIntersectionCandidateFieldsOut" /> </operation> <operation name="FindAddressCandidates"> <documentation>Generates candidates for an address (normal or standardized form).</documentation> <input message="e:FindAddressCandidatesIn" /> <output message="e:FindAddressCandidatesOut" /> </operation> <operation name="ReverseGeocode"> <documentation>Generates an address for a point.</documentation> <input message="e:ReverseGeocodeIn" /> <output message="e:ReverseGeocodeOut" /> </operation> <operation name="StandardizeAddress"> <documentation>Standardizes an address. One of the properties returned indicates if it is an intersection or not.</documentation> <input message="e:StandardizeAddressIn" /> <output message="e:StandardizeAddressOut" /> </operation> <operation name="GetLocatorProperties"> <documentation>Default properties for a locator.</documentation> <input message="e:GetLocatorPropertiesIn" /> <output message="e:GetLocatorPropertiesOut" /> </operation> <operation name="GetStandardizedIntersectionFields"> <documentation>Fields contained in a standardized intersection.</documentation> <input message="e:GetStandardizedIntersectionFieldsIn" /> <output message="e:GetStandardizedIntersectionFieldsOut" /> </operation> <operation name="GetStandardizedFields"> <documentation>Fields contained in a standardized address.</documentation> <input message="e:GetStandardizedFieldsIn" /> <output message="e:GetStandardizedFieldsOut" />
180
</operation> </portType> <binding name="GeocodeServerBinding" type="e:GeocodeServerPort"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="GeocodeAddresses"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GetResultFields"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GetAddressFields"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GeocodeAddress"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GetDefaultInputFieldMapping"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" />
181
</output> </operation> <operation name="GetCandidateFields"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GetIntersectionCandidateFields"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="FindAddressCandidates"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="ReverseGeocode"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="StandardizeAddress"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation>
182
<operation name="GetLocatorProperties"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GetStandardizedIntersectionFields"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="GetStandardizedFields"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding>
<service name="GeocodMallaActual_GeocodeServer"> <port name="GeocodeServerPort" binding="e:GeocodeServerBinding"> <soap:address location="http://siguegis2:8399/arcgis/services/GeocodMallaActual/GeocodeServer" /> </port> </service> </definitions>
183
ANEXO C
CONVENIO MARCO DE COOPERACION ENTRE LA EMPRESA DE ACUEDUCTO ALCANTARILLADO Y ASEO DE BOGOTÁ E.A.B. – E.S.P. Y LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS
