En el PDC2008 vi el lanzamiento de Windows Azure y de Azure Services. También fui afortunado porque en los Hands on Lab pude desarrollar servicios Azure compatibles. Antes de seguir mas de alguien debe estar preguntándose “… Qué rayos es Azure Services….”.
Para el que esté con esa duda fundamental le puedo contar en pocas palabras que la plataforma de Servicios Azure es una plataforma de servicios “en la nube” alojada en los datacenter de la empresa Microsoft a escala internet. Está plataforma provee la capacidad de publicar servicios construidos en dotnet y adminístralos a través del Web. Además de estos servicios propios Microsoft expone servicios hechos por ellos de alguno de sus productos. Para más información de Azure Services Platform click aquí.
Se ha publicado e internet una nueva versión del Azure Services Trainning kit. La primera versión como les conté la probé en el PDC20008, está trae los siguientes “chiches”:
Pueden descargarlo desde Microsoft Download Center aquí.
Enjoy!!!!
Leyendo sobre como la tecnología de sincronización de Microsoft está siendo usada por Iphone, BlackBerry y otros me encontré con el estudio de Yankee Group “Mobile Banking in the United States: The Evolution of Anywhere Banking” [1], el cual está muy interesante.
Las aplicaciones móviles bancarias son un canal de interacción directa entre el banco y sus clientes. En EEUU el universo de cliente para mobile phone Services es de 200 millones y va creciendo con velocidad.
Los desarrollos de banca móvil pueden caracterizarse en 3 estadios diferentes de interacción entre el cliente y la institución financiera. Esto se muestra en la figura 1. Los estadios son los siguientes:
1. Consultas Simples: acceso a los estados de cuenta desde cualquier parte y a conveniencia del clientes.
2. Banca Interactiva: transacciones de transferencias de fondos, pago de cuentas, auto servicio, etc. La funcionalidad es la que motiva el uso en esté estadio.
3. Rentabilidad: Marketing contextual y basado en posicionamiento, niveles de autoservicio alto. La motivación para estas aplicaciones son la rentabilidad del canal para atender los clientes de la institución financiera.
Figura 1
El cuadro en la figura 2 cruza los estadios de madures de las aplicaciones móviles bancarias con las actividades que el usuario realiza, el segmento objetivo, el valor desde el punto de vista del banco y el cliente y las tecnologías que lo habilitan. En este último punto hay que tener en cuenta que las opciones presentadas están limitadas por el Sponsor del estudio. En mi opinión donde dice JAVA debería decir Mobil Browser o Custom Client.
Figura 2
Un aspecto importante a tener en cuenta al momento de decidir una estrategia de implementación de aplicaciones móviles bancarias es identificar cual es el objetivo que buscamos con estás herramientas tecnológicas. Por ejemplo si queremos una adopción rápida basada en una interfaz de usuario fácil de usar las opciones de Custom Client y Mobile Browser son mejores que aplicaciones SMS. La figura 3 muestra una comparativa entre los distintos tipos de implementación de Mobile Banking (SMS, Mobile Browser y Custom Client) para diferentes aspectos de valor.
Figura 3
Les dejo el estudio para que lo revisen, muy bueno!. Gracias RIM.
Referencias
[1] Mobile Banking in the United States: The Evolution of Anywhere Banking
Gmail ahora se puede usar fuera de línea y sincronizar luego con el servidor central, esto abre las puertas a las personas que requieren movilidad que no siempre están conectadas.
Fuente: http://gmailblog.blogspot.com/2009/01/new-in-labs-offline-gmail.html
Aquí está mi presentación sobre el Rol del arquitecto de Software. Me gustó mucho hacer esta presentación, documentándome sobre el tema caí en cuenta de muchas cosas interesantes sobre las competencias que los arquitectos necesitan, las habilidades técnicas son importantes pero son solo parte del set de habilidades que se necesitan.
Me invitarón a hacer en la universidad de las Americas en Concepción. Es el próximo 15 de enero para la cual mandé la siguiente propuesta.
Titulo: “El Rol del Arquitecto de Software”
Abstract:
Una visión simplista del rol, es decir, que el arquitecto crea arquitecturas y que su responsabilidad es todo lo que está relacionado con hacer aquello. Esto debería incluir Articular una visión de la arquitectura, conceptualizar y experimentar con diferentes aproximaciones arquitectónicas, crear modelos y componentes, documentos de especificación de interfaces, y validar la arquitectura contra los requerimientos y supuestos. Sin embargo, un arquitecto experimentado sabe que este rol se hace cargo no solo de esas actividades técnicas, sino que debe asumir otros papeles políticos, estratégicos y consultivos. Todas estas actividades definen las competencias que el arquitecto necesita para ser exitoso.
En esta presentación exploraremos el rol del arquitecto y sus competencias.
Expositor:
Juan Pablo García
Ingeniero Civil Electrónico
Magister en Tecnologías de la información
Microsoft MVP Solution Architect
¿Es está una gran Película? No lo sé, pero voy a averiguarlo 🙂
Escenario
Estamos trabajando en un proyecto de plataforma de reportes basada en SSRS [2] el cual tendrá una gran cantidad de usuarios por lo que debemos tomar medidas para asegurar buenos tiempos de respuestas con la infraestructura que tenemos. La idea es evitar tener que hacer Render de los reportes cada vez que los usuarios demandan los distintos informes.
En este Post voy a exponer opciones de mitigación de problemas de desempeño en SSRS en escenarios de alto desempeño. Mi fuente de información para este post es el libro de potente libro de Rodney Landrum y Walter Voytek [1]
Cuando se propone una solución de informes basada en un servidor de reportes versus la construcción programática ad hoc de reportes se busca el obtener diferentes beneficios tales como reutilización, control de acceso consistente, desempeño, etc.
En el aspecto de desempeño hay que entender que en una solución de informes de negocio, no todos los informes tienen una variabilidad de los datos tal que sea necesario construirlo cada vez que un usuario lo requiere. En este tipo de informes es donde se puede aplicar técnicas de mitigación para cuidar el desempeño de la solución de informes.
Opciones de Mitigación
Para los informes que tienen datos que no tienen una taza de cambios muy alta podemos aplicar las siguientes técnicas de mitigación de problemas de performance.
Ejecución Agendada de Reportes
La idea es programar la ejecución de reportes en momentos predeterminados. Es el servidor quien ejecuta la consulta y genera el informe sin necesidad de intervención del usuario. Estos informes pueden ser almacenados en el servido y así mantener una perspectiva histórica de los datos.
En la siguiente figura se muestra la página de configuración de los reportes agendados.
Ahora, como el reporte se ejecuta por el servicio (usando SQL Server Agent[3]) sin intervención de humanos , los parámetros del informe deben contener valores por defecto o soportar nulos.
El beneficio de usar reportes agendados es que cuando un usuario carga el informe, ve una “foto” que está ya calculado y formateado por lo que la respuesta es “instantánea”.
Instantáneas (SnapShots)
Esta alternativa consiste en almacenar una foto estática del informe. Existen dos tipos de SnapShots:
Los beneficios de performance de utilizar está técnica son que el reporte ya está pre procesado y que no necesita hacer consultas a la base de datos. La siguiente imagen muestra la configuración del SnapShots.
Caching de Contenido
Está técnica es utilizada cuando los diferentes usuarios ven informes con datos que dependen de parámetros que ellos ingresan. En este caso, el contenido agendado no aplica porque genere el mismo resultado para todos los usuarios. El manejó de Cache de SSRS permite mantener copias de los reportes para cada informe las cuales se generan la primera vez que el cliente ve el informe. Las subsecuentes veces que se pide el informe y si ciertas condiciones coinciden el informe no se vuelve a generar sino que se usa la copia del Cache.
Las condiciones en la cuales un usuario recibirá un informe desde el Cache son:
Esta técnica es muy buena para proteger el desempeño de reportes que consumen muchos recursos al hacer el Render. El Trade-Off es que no se pueden usar en informes que tienen datos sensibles en el tiempo, por ejemplo valores de la bolsa en horario de transacciones.Otro tema importante es preocuparse tanto en Cache como SnapShots es el uso de disco. La siguiente imagen es la configuración del Cache.
Servicio de Subscripción de Reportes
A diferencia de las otras tres técnicas presentadas en este Post, este servicio permite calcular los informes y enviarlo a los usuarios subscritos. Hacer esto evita que los usuarios vayan el servidor de informes y pedir su informe sino que el servicio se los envía. Las opciones de envío son las siguientes:
Usar está técnica tiene el beneficio de poder producir los reportes fuera de horarios punta ayudando así a evitar posibles denegación de servicios por sobrecarga de trabajo. Los informes pueden ser generados en diferentes formatos siendo el formato por defecto el Web Archive, pero podría ser otro como una imagen TIF o un PDF.
Podemos trabajar con dos tipos de subscripciones:
Standard Subscriptions: Es una configuración estática para uno o mas usuarios. Los parametros son los mismos para todos.
Data-driven subscriptions: La lista de suscripción es dinámica y puede ser resultado de una consulta. Esta es la forma más potente de trabajo, pero solo está disponible en la versión Enterprise de SQL.
Referencias
[1] Pro SQL Server 2005 Reporting Services
[2] SSRS
[3] SQL Server Agent
..:: Liarjo of Locksley ::.. 