Existen muchas cosas que se  deben tomar en cuenta cuando se identifican escenarios en los cuales se utilizarán aplicaciones móviles. Por ejemplo el dispositivo que se utilizará para implementar la solución. La funcionalidad más compleja que se agrega a este tipo de soluciones tiene relación  con la administración de las comunicaciones y el intercambio de información entre la aplicación y los servidores de Back-End, ya que se tiene en estos momentos conexiones poco confiables o intermitentes.

Este tema obliga al desarrollar capacidades de trabajo Off-line en cada dispositivo. Para poder desarrollar aplicaciones que trabajen Off-line se debe tener en cuenta aspectos cómo Cache Local de datos, sincronización, transacciones basadas en compensaciones, etc. 

Este problema es conocido como Occasionally Connected Computing (OCC). Para hacer aplicaciones que se comporten bien ante los desafíos del OOC existe un modelo llamado OCC MODEL. 

Las aplicaciones OCC son la nueva generación de aplicaciones empresariales para la plataforma móvil. Las aplicaciones se ejecutan en los dispositivos, no como el Browser que obliga a estar conectado siempre;  donde se ingresan datos, se maneja la consistencia y se le da al usuario la sensación de trabajar sin importar el estado de la conectividad. Los criterios que establecen la diferencia entre una aplicación OCC y cliente servidor o basadas en Browser son:

Ø      Una aplicación OCC, sigue trabajando tenga o no conexión con los servidores centrales.

Ø      La aplicación OCC, trabaja con un Cache de datos local en ausencia de conectividad.

Ø      Las colas de la aplicación actúan al fallar la conectividad (Mensajería asíncrona)

Ø      La aplicación detecta cuando existe conectividad y procesa las colas de mensajes y refresca el Cache de datos local. (Publicación y Suscripción)

Las aplicaciones que cumplen con estos criterios son OCC. 

El martes tengo que dar una conferencia para clientes de mi empresa sobre integración. Es de un nivel técnico comercial. No es fácil plasmar un mensaje claro para estos dos segmentos de audiencia.

La audiencia técnica, suele descalificar de entrada a todos los comerciales y gente que hace presentaciones. En su pragmática mente, cualquier persona que no sepa hacer no es un interlocutor válido. Además muchas veces su visión es consumida por sus actividades del día a día, por lo que no pueden enfocarse en las necesidades futuras del negocio.

La audiencia comercial, no entiende nada del cómo hacer las cosas y no quieren que los agobien con complejidad. Esperan que sus problemas de negocio se resuelvan de manera “transparente” para ellos, y sólo participar el las felicitaciones del final del proyecto.

Ambos tipos de audiencia son válidos, lo difícil es hablarle a los dos en una misma conferencia y que todos se vayan a su casa contentos.

La arquitectura orientada a servicios no es una tecnología, sino una forma de hacer negocios. Ella podrá incluso modificar la forma en que se hacen negocios.

Moverse hacia SOA le constará tiempo y dinero, por lo cual el “driver” por el cual usted toma la decisión de hacerlo debe estar muy bien fundamentada. SOA incrementará su agilidad y eventualmente disminuirá sus costos de desarrollo de sistemas.

Para poder llevar adelante este cambio, y hacer lo correcto, usted debe hacer que la gente de IT cambie su forma de ver el negocio. Esto fuerza a que la gente del lado de negocio postergue oportunidades de corto plazo versus objetivos de largo plazo. Por otro lado la gente de IT debe cambiar su forma de ver los sistemas, pensando ahora en niveles de servicios y reusabilidad.

Definición de SOA

En palabras simples, SOA trasforma las funcionalidades de las aplicaciones en piezas de Lego. Toma una pieza de software con una interfaz bien definida y la pone a disposición de diferentes aplicaciones a través de un contrato de uso. Lugo usted puede construir nuevas aplicaciones como construye nuevas figuras de Lego, uniendo las piezas.

Esto suena a juego de niños, sobre todo la parte Lego de los servicios. Debemos ser escépticos, SOA no soluciona todos los problemas ni es tan simple como suena.

La tecnología es dura, pero el staff es peor

Los precursores de SOA en una organización tienen claro que no será fácil cambiar la inercia de “la forma como hacemos las cosas”. Por eso la mejor aproximación es tomar pequeños procesos de negocio de alto impacto y llevarlos a SOA. Siempre la decisión de que pieza del proceso de negocio será transformada, se debe tener en mente el riesgo y retorno de la inversión.

Lo que se espera como resultado inmediato es que la pieza llevada a SOA reduzca la complejidad de integración y mantención. Esto impacta directamente los costos operacionales del sistema.

Hola,

Un cliente me preguntó ¿Tienes Links de buenas prácticas?

Yo dije “…por supuesto, miles de millones..”

Así que me puse a googlear, no fue nada fácil. Todo el mundo habla de las mejores prácticas pero nadie las explica, clasifica, desarrolla etc.

Así que hablando con diferentes personas y consultando en foros llegué a esta lista de mejores prácticas para ASPNET.

Poderosa recopilación de links

http://weblogs.asp.net/Varad/archive/2005/09/25/425938.aspx

Buenas prácticas organizadas como el ciclo de vida (10 eventos) de ASPNET.

http://www.aspfree.com/c/a/ASP.NET/ASP.NET-Life-Cycle-and-Best-Practices/

Para aplicaciones escalables y rápidas

http://msdn.microsoft.com/msdnmag/issues/05/09/SessionState/default.aspx

http://www.codeproject.com/useritems/ASPNET_Best_Practices.asp

http://www.codeproject.com/csharp/effective1.asp

Mejores prácticas de PAG, diferentes guías.

http://msdn.microsoft.com/practices/guidetype/Guides/default.aspx