Archivos Mensuales: agosto 2007

Aplicación Windows Mobile con BackOffice SAP ¿Cómo sincronizar Datos?

Hola,

Me llegó la siguiente pregunta, muy interesante por eso la subo aquí a la sección de Q&A del Blog.

Problemática

Una empresa quiere desarrollar una aplicación móvil en Windows Mobile que funcione desconectada con datos extraídos de SAP en la mañana (usando la cuna) y por la tarde poniéndolos en el móvil en la cuna subir los datos nuevamente. Para ello utiliza un Web Service que expone el módulo Business Connector.

¿Cómo hacer eso? ¿Usar Active Sync?

“Solucionatica”

En este caso se me ocurren dos soluciones, la primera 100% implementada en Service-Oriented y la segunda una combinación de Data-Centric y Service-Oriented. Para los que no estén familiarizados con estos conceptos, pueden ver este POST.

 

Opción 1: Service-Oriented

Que la aplicación móvil consuma los servicios Web de descarga de datos directamente (cuando está en la cuna) e inserte los valores en la DB. Luego la aplicación trabaja desconectada para al final del día cuando sea puesta en la cuna subir los datos a través de un Servicio Web de Update y solución de conflictos.

 

Opción 2: Mixta Service-Oriented y Data-Centric

En esta solución se utilizaría una base de datos intermedia (MSSQL2005) la cual utilizando SSIS cargaría los datos desde SAP a través del Web Services. Luego, utilizando replicación con la PDA transfiere los datos necesarios para móvil. Luego al final del día se sincronizan los datos utilizando las facilidades de MSSQL y su motor de resolución de conflictos. Por último, SSIS pasa los datos ya consolidados desde MSSQL a SAP a través del Web Services de Upload.

Los Pro y contras de cada solución.

 

Aspecto

Service-Oriented

Mixta

Esfuerzo de programación.

Alto, la resolución de conflictos no es simple

Si MSSQL resuelve los conflictos es trivial.

Costos Licenciamiento

Sin costos adicionales.

Licencia de MSSQL 2005

Rapidez de descarga

Está es más rápida, no tiene SSIS intermediando ni el servicio de replicación de MSSQL.

Tiene una pieza intermedia extra.

Efectividad en resolución de conflictos en datos

Puede ser 100% efectiva, todo depende de la lógica programada.

Tiene las limitaciones del motor de resolución de conflictos de MSSQL, que no es malo pero tiene sus limitaciones.

Administración

Solo se requiere instalar la aplicación.

Además de instalar la aplicación hay que configurar en cada equipo la replicación.

Conocimientos del equipo

Web Services.

Aplicaciones Móviles.

TSQL

Web Services

Aplicaciones móviles

SSIS y TSQL

En mi opinión yo tomaría la opción 1 si tengo un equipo de desarrollo con experiencia. Si no es así me iría por la opción mixta, para no tener que programar la resolución de conflictos.

Salu2

Anuncios

Aproximaciones para manejo de datos en aplicaciones OCC

Los desarrolladores de aplicaciones móviles independiente de la tecnología que utilicen manejan el concepto de computación ocasionalmente conectada (OCC).

Las aplicaciones OCC tienen que tomar una decisión de arquitectura muy importante para enfrentar este problema: Data-Centric y Service-Oriented.

Las aplicaciones que utilizan la estrategia de Data-Centric tienen una base de datos relacional (RDBMS) en el cliente. Las capacidades de esta base de datos son utilizadas para propagar los cambios en los datos locales al servidor, administrando el proceso de sincronización, detectando y resolviendo los conflictos de datos.

La segunda aproximación es utilizar Service-Oriented, que almacena los datos locales en mensajes que son puestos en colas cuando el cliente está fuera de línea. Después que se restablece la conexión esos mensajes son enviados al servidor para ser procesados.

A continuación se desarrollan ambas aproximaciones.

 

Aproximación Data-Centric

Cuando se usa está aproximación, el servidor publica los datos a ser utilizados y los clientes se suscriben a los datos que necesitan, entonces obtienen una copia de los datos que necesitan antes de desconectarse.

Mientras la aplicación esta fuera de línea, los cambios son hechos sobre los datos locales mediante la interacción de la aplicación con sus datos locales.

Cuando el dispositivo vuelve a conectarse, la base de datos local propaga los cambios realizados a los datos locales. También, los cambios hechos en el servidor central son propagados hacia el cliente.

Cualquier conflicto ocurrido durante la fase de unión de los datos es manejado por el motor de resolución de conflictos, en base a reglas. Estas reglas son implementadas tanto en el servidor como en el cliente, de acuerdo a las propias reglas de negocio de la aplicación.

El proceso de fusión (Merge) de los cambios en los datos es conocido cómo Merge Replication. Los cambios pueden ocurrir de manera autónoma tanto el servidor como en el cliente, por esto no se utilizan transacciones ACID. En vez de una transacción, cuando se realiza el merge, todos los suscriptores recibirán el dato cambiado en el publicador.

La principal ventaja de usar esta aproximación es que todo el seguimiento de los cambios está contenido dentro de las funcionalidades de la base de datos. Generalmente, la base de datos incluye código para detectar conflictos de datos a nivel de filas y columnas a nivel de base de datos, códigos de validación y restricciones del dato. En este sentido el único trabajo que se debe hacer es armar el esquema de replicación para la aplicación móvil que optimice la resolución de conflictos y actualización de datos.

En este modelo, la sincronización de los datos es responsabilidad del motor de datos, por lo tanto, no es necesario codificar funcionalidades para ello. Se define que tablas son las que necesitan ser sincronizadas y el motor de datos se encarga de llevar el rastro de los datos, sincronizarlos y resolver conflictos. En este punto, la resolución de conflictos, si los criterios que vienen no son suficientes, pueden extenderse utilizando código.

Por otra parte, al existir una base de datos central, después que los clientes sincronizan los datos, se puede asegurar la convergencia de los datos es completa.

Las desventajas que aparecen al usar este modelo son las siguientes:

  •  No puede ser usado en dispositivos son base de datos.
  •  El deploy de las aplicaciones es cliente por cliente, por la configuración de la base de datos.
  •  El deploy debe ser hecho por un administrador del cliente.
  •  Cambios en el esquema de la base de datos central afectan todos los clientes.
  •  Está atada a un motor de datos.
  •  Si ningún criterio de resolución de conflictos resuelve el problema, este debe ser solucionado por el administrador.

Los escenarios recomendados para usar esta aproximación son:

  • Se controlan los dispositivos clientes para la instalación de la DB.
  • No se requiere interactuar con múltiples bases de datos.

Ø Se puede sincronizar utilizando HPPTS, VPN o la LAN.

 

Aproximación Service-Oriented

Con esta aproximación, los clientes interactúan con el servidor central consumiendo servicios a través de mensajes definidos. Pueden tener o no un cache de datos local. La ventaja es que no se necesita una base de datos local instalada en el cliente. Esto significa que está aproximación puede ser aplicada a muchos tipos de dispositivos sin las restricciones del uso de un motor de base de datos local.

El uso de está aproximación de servicios es particularmente apropiada cuando las aplicaciones deben operar en ambientes como Internet y Extranet. Esto porque es posible habilitar en el firewall la entrada de las peticiones de los clientes, por ejemplo Web Service.

El uso de servicios permite mantener bajo acoplamiento, lo que significa que puede interactuar con diferentes esquemas de base de datos.

La principal desventaja de está aproximación es que es responsabilidad del constructor del sistema codificar toda la funcionalidad que guarda relación con el modelo transaccional de Store and Forware de mensajes, como también implementar la contención de transacciones cuando el cliente está fuera de línea.

El uso de una aproximación de servicios se desempeña mejor en escenarios en los que la aplicación necesita interactuar con muchos servicios diferentes, provistos por diferentes servidores. Se comporta muy bien con múltiples trasportes, ya que es independiente el mensaje al trasporte usado. Por ejemplo un trasporte es Web Services.

Los escenarios recomendados para usar esta aproximación son:

  •  Se quiere una solución desacoplada del cliente y servidor.
  •  Se quiere tener todo el control y flexibilidad sobre la conciliación de los datos.
  •  Se tiene experiencia en desarrollo de software de infraestructura.
  •  Se requiere un cliente liviano.
  •  Existe una arquitectura SOA en la organización dónde instalar el sistema.
  •  Se requiere funcionalidad específica de negocio, la cual se encuentra en el Back-End.
  •  Se requiere flexibilidad en los esquemas de bases de datos del servidor.
  •  La aplicación opera en Extranet o Internet.

Si se quiere desarrollar aplicaciones OCC utilizando una orientación de servicios se deben considerar los siguientes puntos principales:

  • Uso de mensajería asíncrona preferentemente.
  • Administrar la interacción con la red.
  • Data Caching.
  • Implementación del mecanismo Store and Forward.
  • Administrar los datos y las reglas de negocio para solucionar conflictos de datos.

Referencias

[1] Smart Client Architecture and Design Guide

Microsoft Technet & MSDN BReafing, Liarjo, Luisón… nos vemos el 4 en el cine?

Leyendo el Blog de Ernesto Golomb, me encontré con las siguientes preguntas sobre el evento del 4 de septiembre (info aquí).

¿Por qué los desarrolladores deberían asistir?

En mi humilde opinión, los desarrolladores que asistan a nuestro Track van a quedar “listos” para incorporar las tecnologías más “taquilleras” del Framework 3.0. Estas son Windows Communication Foudation y Workflow Foundation. Además como Bonus Track verán alguna de las nuevas funcionalidades de Sharepoint como “Bussiness Process”.

¿Por qué salirse de la oficina para ir a esta actividad cuando hay tanta pega?

Esta pregunta es interesante, si uno no asiste a eventos porque tiene mucho trabajo entonces nunca lo hará porque tener mucho trabajo es una constante en la vida. Yo trabajo en una empresa de proyectos, es decir mi obligación es estar siempre ocupado en proyectos. Por eso si estoy muy ocupado siempre jamas podría estudiar ni participar de eventos, con las tristes consecuencias a que eso conlleva

¿Es que acaso los escenarios que se plantean son realmente los que afrontan los desarrolladores día a día?

El escenario que presentamos es de una compañía de seguros que necesita articular sus procesos de negocio. Esto aplica para todas las industrias y los Developer que vayan podrán extrapolar a cada una de sus realidades lo que vean.

¿Son este tipo de encuentros los que ayudan a encontrar respuestas más rápido, de primera mano y con expertos a los que más que ppt’s les gusta mostrar en vivo cómo aprovechar las tecnologías y herramientas disponibles hoy?

Yo no me puedo catalogar como un experto en tecnologías 3.0, Don Box si lo es. Pero si puedo decir que trabajo en una empresa de software y vemos como nos da ventajas competitivas el incorporar WCF y WF en nuestros proyectos.

Por ejemplo estamos haciendo para un Banco (el mas grande del país) un ESB con WCF no porque seamos innovadores, sino porque reamente aporta a la solución con sus capacidades de comunicaciones multicanal.

Otro ejemplo, programa para la generación de FECUS para una compañía de seguros que reporta a la la superintendencia de seguros y valores dónde WF con su motor de reglas nos permite hacer complejas validaciones sin codificar las reglas en duro en el código.

Estas son las razones porque nosotros adoptamos nuevas tecnologías y no por modas del mercado opresiones de los proveedores de la industria.

Les dejo la invitación al evento, se que estará muy bueno.

Salu2

I Conferencia Latinoamericana de Usuarios de MOSS 2007

Hicimos la presentación con demos en el evento “I Conferencia Latinoamericana de Usuarios de MOSS 2007”.

La “rompimos” tuvimos que retrasar el inicio de la conferencia para esperar que pusieran más sillas para que la gente se pudiera sentar. Se rebalso la sala de clientes.

Al final de la presentación recibimos felicitaciones de 3 asistentes por la presentación.

Quedamos muy satisfechos.

Pueden ver el link de la invitación al evento aquí.

La presentación pueden descargarla desde aquí.

SOA REPORT 2007: Service-Oriented Architecture Graduates to the Enterprise.

Este es un informe que hizo InfoWorld en julio del 2007, recién salido del horno para el público general.

Lo he revisado y tiene interesantes resultados, alguno de los cuales comparto aquí.

Por supuesto mejor lo consiguen y leen completo ustedes mismos para evitar interpretaciones equivocadas de los cuadros que les comparto 😉

salu2

 

BlackBerry ¿Cómo Cargar un JAR sin usar un Servidor BES?

Un estudiante que está comenzando a desarrollar en BlackBerry me pregunta cómo puede cargar un programa cliente Java, JAR/JAD por ejemplo, a su teléfono BlackBerry.

El proceso regular para cargar aplicaciones en el teléfono Blackberry es a través de un Servidor BES (BlackBerry Enterprise Server).

Ahora, describo los detalles de cómo convertir los ficheros JAR/JAD en ficheros ALX/COD, para poder cargar manualmente las aplicaciones en los terminales BlackBerry, por ejemplo, a través del Desktop Manager.

INSTRUCCIONES:

Se requiere que descargues 2 programas y que los instales en el PC/Laptop donde se realizará la conversión de los ficheros. Los programas que se requiere instalar son:

Sun Java SDK:

Lo puedes descargar de la web: http://java.sun.com/j2se/1.4.2/download.html

*** Asegurate que descargues el SDK y no el JRE

RIM Java Development Environment (JDE):

Lo puedes descargar de la web: http://www.blackberry.net/developers/

Yo personalmente tengo instalado múltiples versiones del JDE, pero la conversión de estos ficheros la hice con el 4.0.2

Una vez que ambos programas estén instalados, puedes copiar los ficheros a convertir (los midlets) .JAR y .JAD.

Para facilidad de uso, se pueden copiar los ficheros mencionados antes, al directorio BIN del Java Development Environment, por ejemplo:

c:\program files\Research in Motion\Blackberry JDE 4.0.2\bin\

Para la conversión de los ficheros se utiliza la herramienta RAPC.exe (este ejecutable se encuentra en el subdirectorio BIN de la instalación del programa JDE), a través de la línea de comandos DOS. He resumido el procedimiento y básicamente la línea que debes utilizar en la ventana de DOS para realizar la conversión de los ficheros JAD y JAR en COD y ALX es:

rapc import="C:\Program Files\Research In Motion\BlackBerry JDE 4.0.2\lib\net_rim_api.jar" codename=Sametime75 -midlet jad=Sametime75.jad Sametime75.jar

Donde debes reemplazar el nombre asociado a la variable "codename" y los nombres indicados en la entrada "-midlet jad", que en el ejemplo he llamado Sametime75, por el nombre de la aplicación y el nombre de los ficheros a utilizar.

Recuerda:

– Los ficheros los tienes que copiar en el directorio BIN del JDE 4.0.2 (el JAR y el JAD)

– El programa RAPC lo debes ejecutar desde la carpeta BIN también

Una vez que ejecutas el comando RAPC, se genera el fichero .COD en la carpeta BIN. Para generar el ALX, sólo necesitas el NotePad de Windows y editar la siguiente plantilla que te anexo:

<loader version="1.0">
    <application id="SAMETIME">
        <name>SAMETIME</name>
        <description>Version 7.5</description>
        <version>7.5</version>
        <vendor>Vendor Name</vendor>
        <copyright>Not needed but can be anything</copyright>
        <fileset Java="1.0">
            <files>
                Sametime75.cod
            </files>
        </fileset>
    </application>
</loader>

Nuevamente reemplaza los nombres donde he incluido "Sametime", con el nombre de tu aplicación, y reemplaza las entradas como "description", "version" y "copyright", con la información que quieras agregar. Luego "salva este fichero como tipo ALX", NO como texto (TXT).

Con esto ya tendrás el fichero .COD y el fichero .ALX.

Saludos,