048 evolution 2-arquitectura_de_las_smart_devices
•Descargar como PPTX, PDF•
0 recomendaciones•304 vistas
Recomendados
Recomendados
Más contenido relacionado
Más de GeneXus
Más de GeneXus (20)
048 evolution 2-arquitectura_de_las_smart_devices
- 1. X Ev 2: Arquitectura de las aplicaciones Smart Devices @PabloMazzilli #GX2489
- 3. Aplicaciones Nativas Integrada a SAP BO PesoBook.com M-Shop
- 6. Guidelines
- 11. WWSD Pattern
- 13. APP
- 14. APP
- 15. Acciones Locales
- 16. Acciones Locales
- 17. APP
- 18. Acciones Remotas
- 19. APP
- 20. Datos
- 21. WWSD Objects APP
- 22. Además del pattern WWSD…
- 23. SD Panels + Web Services RestProtocol = True
- 24. Build API Web Server APP
- 25. Deployto Cloud API Web Server APP
- 26. Seguridad
- 27. GAM
- 28. Seguridad GAM HTTPs API Web Server GAM APP
- 30. ¡Muchas Gracias! @PabloMazzilli #GX2489
Notas del editor
- Cuando hablamos de aplicaciones que corren en Smart Devices, nos vamos a encontrar en el mercado con dos tipos de soluciones:Aplicaciones Web ejecutándose en el dispositivo.Aplicaciones Nativas.Hay un cierto debate sobre cual opción tomar, considerando los costos y beneficios de desarrollar una aplicación para cada arquitecturaPor un lado tenemos la opcion Web. Es decir, tal cual desarrollamos hoy una aplicación Web, pero con foco en estos dispositivos. La ventaja más clara en este caso es el cross-plarform, es decir, tengo una única aplicación que sé que se va a ejecutar en cualquier dispositivo, dado que solo requiere un browser. Pero no debemos olvidarnos de que estamos hablando de dispositivos PERSONALES, donde la userexperience de las aplicaciones juega un rol fundamental y debería ir acorde a las funcionalidades que brinda cada dispositivo. Los smartdevices abren nuevas oportunidades de interacción del usuario con la aplicación y debemos sacar el mayor provecho de las opciones que brinda cada dispositivo y no bloquear al usuario con interfaces genéricas como pueden ser las web. Claro, desarrollar aplicaciones nativas implica conocer una nueva arquitectura, aprender nuevos lenguajeS, y es en plural, porque no puedo despreciar ninguna plataforma, ya que es el usuario el que optará qué tipo de dispositivo utilizará, lo que en muchos casos hace que esta alternativa sea costosa y en algunos casos hasta inviable.Ahora, esta discusión deja de ser un problema para Uds. Con GeneXus si bien ya sabemos desarrollar aplicaciones Web, ahora tambien podemos desarrollar ese tipo de aplicaciones Nativas, y asi utilizar todos los recursos de cada dispositivo (gps, camara) interactuar con las funcionalidades (otras aplicaciones)instaladas en el device (calendario, agenda, telefono),etc sin necesidad de aprender un nuevo lenguaje, ya que basado en una unicaespecificacion a la gx-way es el propio GX el que se encargará de generar la aplicación en forma nativa para todas las plataformas líderes del momento. Esto no solo implica la aplicación en sí, sino todo los componentes de esa arquitectura, que es lo que veremos con mas detalle en esta charla.
- Permítanme ilustrarles la idea con 3 ejemplos concretos de aplicaciones que están siendo presentadas en este encuentro:El primer grupo son las que llamamos “Line of Business” , en el sentido que son complementos a nuestras aplicaciones de negocio. Es decir, ya tenemos nuestro sistema y queremos aprovechar la obicuidad que nos permiten los dispositivos “moviles” de poder acceder a mi app para realizar tareas puntuales (80/20). Lo que vemos es un ejemplo de una aplicación SD desarrollada por Heuristica para un cliente, que se integra a traves de servicios a SAP Business One para realizar algunas tareas puntuales, como la aprobación de un pedido, ver los contactos de negocio, etc. (tareas que ya realiza desde su version web)Caracteristicas: Es para uso interno, podria hasta tener control de los dispositivos soportados. El segundo grupos son las llamadas “ConsumerApplications” . Como son Pesobook, Gx-Bus. Aplicaciones consumidores finales, donde a traves de los market puedo llegar a miles de personas. Son aplicaciones “auto-contenidas” El tercer grupo es una combinación de ambas, es el caso de M-Shop, que permite realizar compras por ejemplo para un supermercado a través del dispositivo. Tambien es un componente adicional de mi negocio, pero es un utilidad que quiero disponibilizar a clientes y potenciales clientes a través de los markets.Ahora, que tienen en común todas estas aplicaciones: Sigue las reglas de intefaz de c/dispositivo para que la experiencia del usuario sea acorde a su dispositivo personal. Se integran con funcionalidades o aplicaciones propias de cada dispositivo (la camara para leer el codigo de barras, la agenda, el calendario, mail, etc)2) Estan fuertemente orientadas a datos. Es decir, no estoy hablando de juegos ni utilidades. Pero ademas los datos tienen que estar en un servidor, centralizado, esto nos da las siguientes ventajas: Accesibilidad desde cualquier lugar, en cualquier momento con cualquier dispositivo o computador. El pedido de compra la quiero poder validar en cualquier momento; poder registrar mi peso en el momento mismo que me estoy pesando; poder ir armando el carrito de compras desde el momento mismo que se me termina la leche (leyendo el codigo de barras del recipiente en ese momento)Integración con otros sistemas. El primer caso accediendo a SAP.Proveer funcionalidades “sociales”. Por ejemplo, el caso de pesobook, no solo quiero registrar mi peso (para eso no precisaría los datos en un server) sino que además me interesa saber como estoy con respecto al promedio (bueno, en realidad no sé si realmente quiero saber eso ) y para esto es necesario tomar informacion de los cientos o miles de usuarios que utilizan la misma aplicación. En el caso de M-Shop me interesa ver los reviews que han realizado otros usuarios en los productos, lo que podria influir en mis compras. Ver información siempre actualizada (el precio del producto)Ni que hablar de garantizar seguridad en los datos. Para algunos escenarios será imprescindible. Por ejemplo para consultar la lista de charlas del evento no me interesa seguridad, pero si para poder modificarlas o para acceder a datos corporativos.Entonces esta claro que los datos tienen que estar en un servidor. En resumen estamos hablando de aplicaciones nativas, que se ejecutan en el propio dispositivo, y conectadas, cuyos datos son consumidos desde un servidor.----------------------------------------Mas info:Van a comenzar a ver que casi cualquier aplicación de negocio podria tener un componente mobile. Y que ademas, podemos crear “consumerapplication” de manera sencilla y accesible para todo el mundo.Tenemos por un lado un incremento exponencial de dispositivos inteligentes + usuarios conectados en cualquier momento/lugar y la tecnologia para desarrollar aplicaciones para dichos dispositivos (cloud, GX). Lo que me ha pasado ahora, y seguramente a Udstambien, es que a cualquier aplicación le ves un componente que pueda estar ejecutando en el dispositivo (80/20). Lo otro bueno, pero ahí depende mas de la creatividad, es que tenes la todo para crear tu propia aplicación, esa que siempre quisiste tener en un dispositivo o que puede ser de utilidad para una determinada comunidad.
- En concreto una solución SDdesarrollada con GX se compone básicamente de :1) Un componente nativo (*), generado en el lenguaje del dispositivo (Objective-c para iOS, Java para BB y Android), que sigue los estándares de UI y recomendaciones de cada plataforma (mejora la experiencia del usuario, es publicable en los stores) y se integra con las aplicaciones de cada device (agenda, mapas, contactos, telefono, etc) y consume datos desde un servidor Web. 2) Un conjunto de servicios que atienden los request del dispositivo, eventualmente se conectan a la base de datos y retornan el resultado al dispositivo. Entonces una aplicación SD Nativa es solo una parte de la solución completa que también tendrá un componente Web (servicios y opcionalmente un Backoffice). Dichos web services no son mas que servicios REST , lo que habilita que tambien puedan ser utilizados por otras aplicación Web (pensando en una arquitectura web de 3 capas por ejemplo). Veamos como se genera dichoscomponentes desde GX.(*) Esto no invalida que la aplicación nativa puede tener un component web incluido, por ejemplo para resolver cierto funcionalidad no soportada por la plataforma.
- Entonces, es claro que vamos a precisar generar contenido en el dispositivo, para cada plataforma, y publicar servicios en el servidor Web para proveer los datos y acciones a la aplicación que se está ejecutando en el SD.Es por esto que cuando comenzamos a trabajar en nuestra KB con objetos Smart Device, además del generador Web que ya conocemos (.net, java o ruby) y que se utilizará para generar la capa de servicios (y el backoffice web), se agrega un nuevo generador en nuestro Environment, el Generador Smart Device.
- Para entender los diferentes componentes que participan de esta arquitectura, empecemos por unos de los objetos nuevos introducidos en la versión, el WWSD Pattern y veamos que es lo que se genera en cada capa. Que en definitiva no son más que objetos GeneXus (aunque algunos no esten visibles en la KB) y así poder ver como extender las funcionalidades que el pattern nos provee automáticamente y potenciar aún más nuestras aplicaciones SD.
- Tomemos como ejemplo la aplicación del Programa del XXI Encuentro.Esta aplicación es el resultado de aplicar el WWSD Pattern a ciertas entidades de nuestra KB, como ser la Transaccion de Conferencias, Speakers, etc. Lo mismo con el sistemas M-Shop, donde se aplica el WWSD Pattern a la TRN de Productos.
- El WWSD aplicado sobre una TRN genera en tiempo de diseño un conjunto de objetos.Los mas visible son los Paneles o Layouts: para el List, Detail, Relations. Ahí e donde nos ocuparemos de todos los aspectos de diseño: posicion de los campos, imágenes, acciones, etc.Y por otro lado tenemos los datos con los cuales va a interactuar, determinado por los atributos o servicios definidos en cada Layout.
- A partir del Layout se genera una metadata, que es un conjunto de archivos json que describen el formato de la pantalla, sus acciones y servicios a invocar. Ademas de un archivo de resources que contiene todo lo referente a imágenes y language.Ver presentación: Las más lindas son mejores (Hoy 10:30 mima sala)
- Ver Presentacion: Nativeapplications Rock! (Hoy 11:00 misma sala)
- GX dispone de una API para interactuar con las funcionalidades de los dispositivos. Para esto se tiene una API generada en cada uno de los lenguages nativos soportados y un EO que se importa automaticamente en GX para utilizar esos recursos.La arquitectura extensible de GX da la posibilidad de incorporar nuevas funcionalidades en la API.
- Habra casos en donde podria querer alguna acción en el dispositivo para realizar determinado procesamiento en el servidor. Para esto tenemos la posibilidad de definir nuevas acciones.
- En este ejemplo tenemos una accion en el dispositivo para agregar el producto en el carrito (AddToCart). Esto lo hacemos a traves de una acción. Dicha acción termina llamando a un servicio, sea un proc o el propio BC del carrito para insertar esa información en la tabla correspondiente.A nivel de layou insertamos la acción e indicamos el objeto a llamar (Procedure o BC)Luego definimos el Proc como Servicio REST o la TRN Carrito como BC Rest.
- Diseño UI: Link a la charla de Ursula/Ma InésAcciones Locales: Link a la charla de Franklin
- Del pattern se infiere además los diferentes servicios a ser invocados. Por ejemplo, voy a precisar una servicio que retorne la lista, como las de Conferencias, Productos.Para esto diponemos de los Data Providers, que en este caso se generan automaticamente y ya resuelven todo el tema de pagina, para optimizar las consultas al servidor.Además vamos a querer visualizar el detalle de un elemento de la lista, y en algun caso hasta poder dar de alta, modificar o eliminar ese elemento directamente desde el SD. Para esto tenemos la TRN y como en este caso queremos acceder a esos recursos a traves de servicios, lo que hace el pattern es definir la TRN com BC y exponer sus métodos como Web ServicesRest.De esta forma tenemos acceso a todo el CRUD de la TRN, y nos aseguramos que las reglas de negocio definidas en la TRN tambien se tengan en cuenta cuando ejecutamos esos métodos (insert, update, delete) desde el dispositivo.Ademas las pantallas como estan usando los BC tengo toda la potencia del dialogo pseudo-conversacional.
- Hasta aquí vimos como se generan los componentes tanto en el clietne como en el servidor a patir de la metadata generada por el WWSD Pattern. Pero se dispone ademas de un objeto SD Panel, que permite crear nuestros propios Layouts, por ejemplo para resolver algunas interfases que el patterno no aplica: Login o EntryPanels en general.Visualizar datos que implica navegar varias tablas o información que directamente no está en la base de datos o que surge de consumir un servicio externo.Este objeto tambien genera una metadata tal cual el pattern WWSD (incluso si tiene atributos tambien genera los servicios correspondientes)
- En caso que necesite crea nuevas intefaces, tenemos entonces los SD Panels. Crean nuevos servicios es sencillo, basta con crear el objeto necesario (Proc, DP, BC) y cambiar la propiedad para exponerlo como servicio REST. GX se encargará de generar la api rest correspondiente al objeto y resolver la invocación y respuesta del web service.
- En el proceso de build se crea el paquete para cada plataforma tomando la información de esa metadata y se incluye además los programas estándar (SD API) para la interacción con las funcionalidades del dispositivo.Ese es el componente que será compilado para cada plataforma que queramos en el lenguaje nativo: Objective-c para iOS, Java para BB y Android con el Generador SmartDevice.Del otro lado tenemos la api REST que proveen los servicios que la aplicación necesita.Todos los servicios quedan expuestos entonces en una interface en el servidor WEB, desde el cual el dispositivo accederá según la información contenida en la metadata. Son servicios REST lo que permite una comunicación eficiente entre el cliente y el servidor.La comunicación es a través del protocolo http y el formato de los archivos transferidos es json, un formato liviano y simple.INTEROPERABILIDADEsos servicios no son exclusivos para las appsmartdevice. Podria integrar otras aplicaciones (web, nativas) a traves de estos servicios REST.
- En el proceso de build se crea el paquete para cada plataforma tomando la información de esa metadata y se incluye además los programas estándar (SD API) para la interacción con las funcionalidades del dispositivo.Ese es el componente que será compilado para cada plataforma que queramos en el lenguaje nativo: Objective-c para iOS, Java para BB y Android con el Generador SmartDevice.Del otro lado tenemos la api REST que proveen los servicios que la aplicación necesita.Todos los servicios quedan expuestos entonces en una interface en el servidor WEB, desde el cual el dispositivo accederá según la información contenida en la metadata. Son servicios REST lo que permite una comunicación eficiente entre el cliente y el servidor.La comunicación es a través del protocolo http y el formato de los archivos transferidos es json, un formato liviano y simple.INTEROPERABILIDADEsos servicios no son exclusivos para las appsmartdevice. Podria integrar otras aplicaciones (web, nativas) a traves de estos servicios REST.
- Como los servicios estan en un servidor web , se vuelve esencial tener un mecanismo de seguridad para acceder a éstos (y tambien a la aplicación web). Con este fin se ha incluido en la xev2 un modulo de seguridad llamado GAM (GX Access Manager), que se habilita através de la propiedad “EnabledIntegrated Security”. Esto hace que cualquier acceso a esos servicios (y tambien de la aplicación Web en caso que lo desee) tiene ahora que pasar por un dialogo de autenticación (login). Ver Presentaciones: ¿Qué resuelve GX Evolution 2 para la seguridad de sus aplicaciones Web y SD? (Martes 14:30 2ª)Cómo incorporar seguridad a mis aplicaciones GeneXus (Martes 15:00 2ª)Además de la seguridad a nivel de aplicación, es importante agregar seguridad en el canal, habilitando el protocolo https.
- Con este nuevo generado tenemos la posibilidad de sorprender a nuestros clientes, creando rápidamente soluciones nativas de alto impacto. Aprovechemos la posibilidad de crear prototipos en la nube (si no disponemos de un servidor web) para actuar proactivamente con nuestros usuarios, clientes, acercándoles prototipos funcionales, y explotemos nuestra creatividad para desarrollar nuestra propias aplicaciones.De la idea al hecho, en este caso, realmente ahora tenemos un camino corto y muy fácil por recorrer. Aprovechémoslo !
- Muchas Gracias!PD: Si deseas compartir algo de esta charla o plantear dudas, puedes escribirme a pmazzilli@genexus.com o viatwitter (@PabloMazzilli) utilizando el hashtag #GX2489.