The Journal Architecture N 14

Aprenda la disciplina,
ejerza el arte y
contribuya con sus ideas en
www.ArchitectureJournal.net
Recursos que sirven de base
Journal 14
Arquitectura mvil
Consideraciones de
arquitectura para un
mundo de dispositivos
Mejores prcticas:
extensin de aplicaciones
empresariales para
dispositivos mviles
Experiencia de
consumidor conectada en
automviles
Perfil del Architecture
Journal: Faisal Waris
Arquitectura de datos
mviles
Desarrollo guiado por
pruebas e integracin
continua para
aplicaciones mviles
Estudio de un caso:
Brindar asistencia a los
tcnicos en el campo de
operacin
Contenido
Journal 14
Prlogo
Por Simon Guest
Consideraciones de arquitectura para un mundo de

dispositivos
Por Atanu Banerjee
Explore las consideraciones y aspectos de arquitectura en el diseo de aplicaciones para dispositivos mviles.
Mejores prcticas: extensin de aplicaciones empresariales

para dispositivos mviles
10
Por Kulathaumani Hariharan
Descubra mejores prcticas y recomendaciones para la extensin de aplicaciones empresariales hacia

dispositivos mviles.
Experiencia de consumidor conectada en

automviles
17
Por Christoph Schittko, Darryl Hogan y Jon Box
Cmo se puede extender un automvil para que admita capacidades de software ms avanzadas?
Explore un escenario y consideraciones de arquitectura para la creacin de experiencia de consumidor
conectada.
Perfil del Architecture Journal: Faisal Waris
24
En nuestro primer perfil de arquitectos externos, hablamos con Faisal Waris sobre
su funcin, pensamientos respecto de dispositivos mviles y tendencias generales
de arquitectura.
Arquitectura de datos mviles
26
Por Rodney Guzman
Cules son los desafos de datos asociados con aplicaciones mviles conectadas ocasionalmente? y Cmo
se pueden superar?
Desarrollo guiado por pruebas e integracin continua para

aplicaciones mviles
31
Por Munjal Budhabhatti
Descubra el modo en el que el desarrollo guiado por pruebas y la integracin continua pueden ayudar a
incrementar la confiabilidad de las aplicaciones, as como tambin la forma en la que ambos enfoques
funcionan en aplicaciones mviles.
Estudio de un caso: Brindar asistencia a los tcnicos en el

campo de operacin
36
Por Andrs Velvrt y Peter Smulovics
Investigue el estudio de un caso sobre el modo en el que, en Hungra, el soporte a tcnicos en el campo de
operacin se beneficia de una aplicacin mvil de ltima generacin.
Recursos
que sirven de base. www.architecturejournal.net
Fundador
Arvindra Sehmi
Microsoft Corporation
Prlogo
Jefe Editor
Simon Guest
Consejo Editorial de Microsoft
Gianpaolo Carraro
John deVadoss
John Evdemon
Neil Hutson
Eugenio Pace
Javed Sikander
Philip Teale
Editor Comercial
Lisa Slouffman
Diseo, Impresin y Distribucin:
CMP Technology Contract Publishing
Chris Harding, Director Gerente
Angela Duarte, Gerente de Publicacin
Lisa Broscritto, Gerente de Proyecto
Kellie Ferris, Directora Corporativa de Servicios
Creativos
Jimmy Pizzo, Director de Produccin
La informacin contenida en The Arquitecture

Journal (Journal) se brinda slo con fines
informativos. El material publicado en el Journal no
constituye la opinin o asesoramiento de Microsoft
Corporation (Microsoft) o de CMP Media LLC
(CMP) y no debe basarse en ningn tipo de
material publicado en este Journal sin antes buscar
asesoramiento independiente. Microsoft y CMP no
proveen garanta o representacin alguna respecto
de la precisin o aptitud de los fines de cualquier
material del Journal y en ningn caso Microsoft o
CMP aceptan responsabilidad de ningn tipo,
incluyendo responsabilidad por culpa (excepto por
dao contra los derechos personales del individuo o
fallecimiento), por cualquier tipo de daos o
perjuicios o prdidas (incluyendo, sin limitacin,
prdida del negocio, rdito, ganancias o prdida
consiguiente) de cualquier ndole o naturaleza que
resultare del uso del presente Journal. El Journal
puede contener imprecisiones tcnicas y errores de
tipografa. El Journal se actualizar de vez en cuando
y podr otras veces estar desactualizado. Microsoft y
CMP no aceptan responsabilidad alguna por
mantener la informacin de este Journal actualizada
ni por el incumplimiento del hecho. Este Journal
contiene material propuesto y creado por terceros.
Hasta el alcance mximo permitido por la ley
aplicable, Microsoft y CMP excluyen toda
responsabilidad por cualquier acto ilegal que surgiera
de un error, omisin o imprecisin en este Journal y
Microsoft y CMP no se responsabilizan del material
suministrado por terceros.
Las siguientes marcas comerciales son marcas
registradas de Microsoft Corporation: ActiveSync,
RoundTable, Silverlight, SQL Server, Virtual Earth,
Visual Studio, Windows CardSpace, Windows Live,
Windows Mobile, Windows Server, Windows Vista,
Xbox 360 y Xbox Live. Cualquier otra marca
comercial es propiedad de sus respectivos
propietarios.
Estimado arquitecto:
Cada da, la ubicuidad de los dispositivos y telfonos mviles simplemente me
sorprende, en especial, cuando analizo la tasa de crecimiento que se proyecta
para los prximos aos. Con este crecimiento y los avances rpidos en la
tecnologa mvil, me doy cuenta que es muy probable que mis hijos crezcan y
nunca sepan lo que realmente significa un telfono fijo, marcacin por pulso o
marcacin por disco rotativo. En cualquier tecnologa, el software desempea
una funcin importante al complementar este crecimiento fenomenal del
hardware, y ste es el foco de esta edicin de The Architecture Journal.
Para iniciar esta edicin, Atanu Banerjee trata varias consideraciones y
aspectos de las aplicaciones en los dispositivos mviles de la actualidad. Sigue a
este artculo Kulathumani Hariharan, arquitecto en Tata Consultancy Services,
quien comparte mejores prcticas, consejos y recomendaciones que pueden ser
relevantes si se considera llevar una aplicacin de lnea de negocios hacia la
plataforma mvil.
A continuacin, se suman Christoph Schittki, Darryl Hogan y Jon Box
quienes nos presentan un escenario de una experiencia de consumidor conectada
en dispositivos para el automvil. Exploramos cmo podra ser el futuro del
software en automviles y algunas perspectivas de arquitectura que lo
respaldan. Muy relacionado con este artculo, nos complace enormemente
presentar nuestro primer perfil de arquitecto externo en The Arquitecture
Journal. Faisal Waris es consultor de arquitectura que trabaja para Ford Motor
Company. Le preguntamos algunos de sus pensamientos sobre la arquitectura,
en especial, el modo en el que se relacionan con el desarrollo mvil.
Despus de Faisal, Rodney Guzman de InterKnowlogy comparte varios de
sus pensamientos sobre la arquitectura de datos mviles. Rodney explora
algunos de los desafos que enfrentan los datos con aplicaciones conectadas
ocasionalmente y ofrece algunas ideas y conceptos para ayudar a tratar la
resolucin de conflictos de datos. Sumergindonos an ms profundo en el
desarrollo mvil, a continuacin encontramos a Munjal Budhabhatti de
ThoughtWorks, quien trata la importancia del desarrollo guiado por pruebas y la
integracin continua, prcticas de ingeniera comunes para varias organizaciones
y analiza el modo en que se puede implementar esto para aplicaciones mviles.
Finalizamos esta edicin con una viaje a Hungra con Andrs Velvrt y Peter
Smulovics para analizar la forma en la que Monicomp, una organizacin que
instala, mantiene y repara sistemas de puntos de servicio, utiliza una aplicacin
de PC ultramvil para brindar soporte a los tcnicos en el campo de operacin.
Esto da por finalizada esta edicin. Espero que algunos de los artculos y
autores ayuden a inspirar el desarrollo de aplicaciones mviles en su
organizacin. Regresaremos el prximo ao con el Journal 15 sobre la Funcin
del arquitecto, en la que observaremos con ms detalle a las personas en
nuestra profesin y examinaremos bajo lupa el trabajo que hacemos.
Todos los derechos del autor, marcas registradas y

cualquier otro tipo de propiedad intelectual del
material contenido en el Journal pertenecen y son
licencia exclusiva de Microsoft Corporation. Queda
totalmente prohibida la copia, reproduccin,
transmisin, almacenamiento, adaptacin o
modificacin de la forma o contenido del presente
Journal sin previo consentimiento por escrito por
parte de Microsoft Corporation y los autores
individuales.
Simon Guest
2007 Microsoft Corporation. Todos los derechos

reservados.
THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net
Consideraciones de
arquitectura para un
mundo de dispositivos
Por Atanu Banerjee
Sntesis
La cantidad de usuarios que utilizan dispositivos mviles
aumenta rpidamente, pero la promesa de soluciones que
permiten aprovechar redes de dispositivos conectados
contina en gran parte sin cumplirse. Algunas de las piezas
necesarias para construir experiencias conectadas, ricas, no
estaban disponibles hasta hace muy poco. Este artculo
estudia algunas de las tendencias econmicas, sociales y
tecnolgicas que impulsan la adopcin de dispositivos
mviles; describe los diferentes tipos de experiencia de
usuario posibles en la actualidad y presenta una visin
general de las consideraciones de arquitectura asociadas con
esas soluciones de movilidad en los niveles del hardware,
software, conectividad y capacidades de servicios.
Nuevas oportunidades con dispositivos

Despus de 10 aos de expectativas las soluciones de movilidad
finalmente comienzan a tener xito. Uno se puede preguntar: Por
qu ahora? Qu es lo que ha cambiado? Existen nuevas
oportunidades para considerar? Debera considerar los dispositivos
mviles en mis soluciones? Resulta que, las tendencias econmicas
sociales y tecnolgicas estn acelerando el cambio hacia dispositivos.
Existe una amplia gama de dispositivos con diferentes factores de
forma que se ejecutan en distintos tipos de aplicaciones, como se
muestra en la Figura 1 y estn asociados con diferentes grupos de
tendencias.
Tendencias econmicas
Un impulsor importante en la adopcin de telfonos celulares han sido
los mercados emergentes. Por ejemplo, BusinessWeek informa que
en 2001 Nigeria tena 500.000 lneas telefnicas pero en la actualidad
tiene ms de 30 millones de abonados a telfonos celulares. Hoy en
da se estima que para el 2015 habr 5 mil millones de usuarios de
telfonos celulares.
La adopcin de telfonos celulares genera la adopcin de servicios
que se ofrecen para los telfonos celulares. En Asia, varios servicios
aprovechan los dispositivos de alta calidad para ofrecer multimedia
interactiva, rica. Esto requiere computadoras de bolsillo y telfonos
inteligentes de ms alta calidad como se muestra en la Figura 1. Sin
embargo, esos dispositivos no estn al alcance de muchas personas
de los mercados emergentes, por lo tanto, tambin se presentan
servicios que apuntan a telfonos masivos de menor calidad. En
Kenia, Safaricom present un servicio basado en SMS para pagos
mviles en marzo de 2007, denominado M-Pesa, que ha sido
ampliamente adoptado. Como cabe esperar, el acceso a las
comunicaciones mejoradas puede ser inmensamente beneficioso para
las economas locales. El Dr. Robert Jensen de la Universidad Brown
dirigi un estudio de pescadores de India que comenzaron a utilizar
telfonos celulares para encontrar los mejores mercados costeros
para sus pescas. Si bien los pescadores percibieron un incremento de
las ganancias de un 8 por ciento, en realidad, los precios de los
consumidores disminuyeron un 4 por ciento ya que se desperdiciaba

menos pescado.
Hoy en da en Helsinki, Finlandia, el 57 por ciento de los boletos
de ida de los transportes pblicos se pagan a travs de los telfonos
celulares. En Croacia, ms de la mitad de todos los estacionamientos
se pagan mediante los telfonos celulares. El 20 por ciento de las
tarifas de congestionamiento en Londres se paga a travs del
telfono celular. (Ver Recursos: Mobile Phones As Mass Media).
Tendencias sociales
Existen en la actualidad ms de dos telfonos mviles en el mundo
por cada computadora personal. La industria inalmbrica utiliz la
apertura de su ms amplia exposicin comercial en marzo para
describir las oportunidades de un mundo de tres pantallas (PC, TV,
mviles), en el que los dispositivos mviles se convierten en la lnea
principal para los programas de televisin, msica, juegos y
publicidad. Para muchos consumidores ms jvenes, podra
debatirse incluso que el dispositivo mvil es la el ms importante de
esas tres pantallas.
Acompaando el crecimiento de los dispositivos, la evolucin de
Internet se dirige hacia nuevos patrones de uso. Las soluciones de
hoy en da se diferencian de las anteriores por su escala y alcance
global, lo que lleva a nuevos canales que permiten la participacin
de los usuarios. Por ejemplo, la compaa de productos para el
deporte Nike vende Nike+, un pequeo sensor que se coloca dentro
de la zapatilla del corredor y mantiene un registro de su progreso en
un iPod que tambin lleva el corredor. Cuando el iPod de Apple se
conecta a una PC, los detalles de la carrera del corredor se envan al
sitio Web de Nike+, un sitio social en red para corredores, para que
Figura 1: Variedad de dispositivos mviles y tipos de aplicaciones
que se ejecutan en ellos.
Dispositivos
Telfonos
PCs porttiles
Aplicaciones de
movilidad
Aplicaciones
accionador/
sensor
Aplicaciones
personales de
informacin y
salud
Dispositivos
personalizados
incorporados
Objetos
pesonales
inteligentes
Tablet PC
PC Notebook
PC de
bolsillo
Telfono
inteligente
Telfonos
masivos
PC ultra-mvil
(UMPC)
Aplicaciones
tradicionales de
escritorio
Aplicaciones
limitadas
Secuencia de los dispositivos mviles
www.architecturejournal.net - Journal 14 THE ARCHITECTURE JOURNAL
Consideraciones de arquitectura
Figura 2: Las experiencias de usuario en un mundo de dispositivos
conectados abarcan mltiples espacios fsicos y virtuales. Cada uno
de los puntos azules representa un entorno fsico (una sala, una casa,
un lugar de trabajo), un entorno social (amigos, familia, colegas), un
entorno virtual (pgina de perfil, mundo virtual, juegos en lnea) o un
servicio suscripto en lnea.
Contenido y multimedia
Comunicaciones (Correo electrnico, IM, SMS,Voz)
Solicitudes /mensajes de control
Usuario
Entorno inmediato
Entorno remoto
Redes sociales
Servicios suscriptos
Mensajes (Correo electrnico, IM, SMS, Voz)

Eventos /notificaciones
Feedback
Cambios en el entorno
los corredores de todo el mundo puedan formar grupos y ver los

progresos y rutas de los otros corredores.
Internet tambin est cambiando la forma en la que se crean los
contenidos. Los blogs hacen que la publicacin de contenidos sea
menos impersonal ya que los lectores estn ms en contacto con los
autores. El contenido tambin se vuelve ms interactivo y social con
los juegos en lnea, el chat y el advenimiento de comunidades en
torno de contenido que generan los usuarios. Esta tendencia va a
aumentar con la proliferacin de dispositivos mviles que facilitan la
captura de contenido para editarlo directamente desde el dispositivo,
adjuntar contexto en contenido recientemente creado y a
continuacin cargarlo para almacenarlo, ya sea en una PC o en la
nube. En algunos escenarios P2P tambin es posible compartir
contenido directamente desde el dispositivo mismo.
Esta transformacin en los canales de contenidos posibilita an
ms que la creacin de contenido sea disparada por eventos externos
en vez de en programaciones fijas. La manejabilidad de los
dispositivos posibilita cada vez que la forma de registrar un evento
est disponible cuando sucede, lo que lleva a la creacin espontnea
de contenido nuevo que de otra forma no podra haber sido
capturado. No es sorprendente que la cantidad de contenido que se
genera y se almacena se haya utilizado al mximo. El aumento
repentino en la capacidad de los ciudadanos de registrar eventos de
forma espontnea ha dado como resultado, en ms de una ocasin,
grabaciones filmadas desde dispositivos que han provocado en el
pblico una notable reaccin.
Tendencias tecnolgicas
La primera tendencia que vuelve a dar forma a la industria es la
convergencia. Hoy en da las personas utilizan una gran variedad de
dispositivos: telfonos inteligentes, PDAs, laptops, reproductores
multimedia personales, cmaras y videograbadoras. Se espera que
estas tecnologas se integren dentro de dispositivos informticos
personales de propsito general ms poderosos, que se puedan
utilizar para una gran variedad de negocios y tareas orientadas al
consumidor. La convergencia en las redes dar lugar a la
manipulacin transparente de voz y de datos a travs de los mismos
protocolos.
La convergencia conduce a una segunda tendencia: Los dispositivos

se hacen cada vez ms inteligentes. Una nueva generacin de
telfonos inteligentes es cada vez ms consciente de los entornos del
usuario y del contexto local, a travs de sensores, como el GPS o el
acelermetro, y un mejor software en los dispositivos. Este contexto se
podra utilizar para etiquetar contenidos (Por ejemplo, etiquetar una
fotografa con metadatos de ubicacin/tiempo), para adaptar el
comportamiento de una aplicacin (Por ejemplo, no enviar alertas de la
aplicacin cuando el usuario mantiene una conversacin telefnica) o
para controlar el entorno local del usuario (como configuraciones en el
auto-ajuste de un vehculo basadas en la identidad de usuario que se
ha recuperado desde un dispositivo colocado en el cuerpo del
conductor. Las redes tambin se extendern para cubrir dispositivos y
agentes distribuidos en el cuerpo sobre protocolos como Bluetooth, que
es la idea de las Redes de rea Personal (PANs). Todo esto aportar
nuevas arquitecturas en las que los dispositivos son mucho ms que
simples pantallas de informacin, se convertirn en plataformas de
aplicacin de primera clase por s mismos. No slo esto, sino que
tambin muy probablemente habr algunos escenarios, como las PANs,
en los que varios dispositivos actuarn como servidores de otros
dispositivos (en arquitecturas cliente-servidor) o como servidores de
ndice o super-peers (en arquitecturas P2P).
Esto es importante ya que las aplicaciones de los dispositivos
mviles deben ofrecer una experiencia de usuario que sea muy
diferente a la que ofrece un escritorio. La caracterstica clave de los
usuarios mviles es que ellos estn ocupados con algunas otras
actividades primarias. Una aplicacin basada en un dispositivo no debe
obligar a sus usuarios a que hagan ajustes, sino ms bien debe
adecuarse a la vida y estilo de vida de las personas siendo consciente
del contexto, no intrusivo y debe estar listo para brindar valor
rpidamente a corto plazo.
La tercera tendencia es Internet mvil, una recopilacin de servicios
y sitios de Web especficamente orientados a dispositivos mviles y
disponible en los protocolos de Internet. El crecimiento de la Web mvil
acelerar el consumo de aplicaciones y servicios basados en Internet
desde dispositivos mviles, lo que en la actualidad est restringido por
las limitaciones de planes de acceso de los mviles y dispositivos.
La combinacin de estas tres tendencias dar como resultado un
avance hacia la informtica pervasiva. A medida que los dispositivos
proliferan y se vuelven ms inteligentes, se incorporar ms potencia
informtica en los bordes de la red. A medida que los dispositivos
mejoran el manejo del contexto del usuario, se volvern cada vez ms
sencillos. A medida que los dispositivos se conectan mejor a las redes y
la Internet mvil evoluciona, los usuarios tendrn a su disposicin un
conjunto rico de servicios que puede hacer uso de este contexto
personal. Los lmites entre los entornos humanos y los dispositivos
informticos desaparecern poco a poco y los usuarios comprendern
el sentido de ser asistidos por sus entornos inmediatos. Una gran
cantidad de dispositivos informticos incrustados impondr nuevas
arquitecturas de solucin para tratar los desafos emergentes en torno
a la experiencia del usuario, gestin de dispositivos, seguridad, gestin
de contenido, etc. Es necesario que el acceso a la red est disponible
universalmente. Si bien claramente no llegamos an al punto de la
informtica global, avanzamos hacia esa direccin con el crecimiento
de los telfonos inteligentes y dispositivos incorporados, la expansin
de conectividad inalmbrica en todos nuestros entornos (desde lugares
de trabajo, viviendas hasta algunos vehculos) y la amplia
disponibilidad de servicios de Internet que se pueden acceder a travs
de los dispositivos.
Cmo ser la experiencia del usuario?
A medida que los dispositivos se vuelvan ms comunes, el software
deber abarcar una variedad de dispositivos conectados a la Web as
como tambin adoptar el creciente dominio de Internet, un patrn
fundamental de Web 2.0 que Tim OReilly describe como software por
encima del nivel de un nico dispositivo. Los dispositivos se utilizan en
mltiples espacios fsicos y virtuales (Figura 2, arriba).
Figura 3: Red social en los dispositivos
ENCONTRAR
EXPLORAR
Conexin con amigos

COMPARTIR
COORDINAR
Experiencias relacionadas con el usuario

Los dispositivos en estos escenarios, por lo general, se utilizan para
las comunicaciones (telfono, correo electrnico), recopilacin de
contenido (bsqueda mvil), consumo de contenido (reproductores
multimedia personales) y para el control de la salud (control del ritmo
cardaco). El alcance de la aplicacin en estos escenarios se centra en
la informacin que se recopila sobre uno, que se crea para uno o que
uno mismo consume directamente. La informacin relevante incluye
credenciales (Live ID), contactos, mensajes, informacin de presencia
y contenido personal (audio, video). Los tipos de dispositivos que son
importantes incluyen telfonos celulares, telfonos inteligentes, PDAs,
Ultra-Mobile PCs (UMPCs), laptops y controles de la salud. La
conectividad necesaria es para las Redes de rea Personal (PAN) de
Bluetooth, sensores para la salud, etc.
Experiencias relacionadas con el entorno local
Como se describe anteriormente, la proliferacin de dispositivos
inteligentes conducir a espacios en los que los lmites entre el
entorno inmediato de una persona y los dispositivos informticos de
ese entorno desaparecen. Esto se lograr mediante dispositivos
conectados en red con sensores incorporados (GPS, acelermetro,
sensor de luz ambiente) que comprendan el contexto del usuario y
sean discretos en sus acciones para que los usuarios comprendan el
sentido de ser asistidos por su entorno.
Un ejemplo de ese tipo de entorno es la solucin Microsoft Auto
que conecta los dispositivos de un usuario, como telfonos celulares y
reproductores multimedia porttiles, en un nico sistema dentro del
vehculo que se puede operar con la voz del conductor o botones que
se encuentran en el volante. La empresa Ford Motor lanzar en 2008
una solucin denominada Ford Sync, que implementar experiencias
de usuario mviles de nueva generacin: por ejemplo, los usuarios
que ingresan a un vehculo mientras hablan por telfono celular
podrn presionar un botn en el volante para que el telfono se
conecte a Sync sin interrumpir la llamada. Otro caso de extensin de
un entorno automotor con dispositivos es el de OnStar que ofrece
seguridad y asistencia en las rutas: dentro del vehculo, se conecta a
la radio un dispositivo de comunicaciones, una antena GPS, y un
micrfono va una red incorporados dentro del vehculo (o bus).
Las salas de conferencias tambin se estn extendiendo con
dispositivos. Microsoft RoundTable es una combinacin de micrfono
y cmara de videoconferencia que utiliza un sistema de deteccin de
sonido y movimiento para cambiar el nfasis hacia el conferenciante
que habla. Eliminar la necesidad de que los conferencistas deban
moverse para mirar una cmara fija cuando comienzan a hablar sigue
la lnea de la idea de que los dispositivos se vuelvan menos molestos
en sus acciones.
En algunos casos, es posible que los dispositivos necesiten compartir
informacin con otros dispositivos que tambin se encuentran prximos
al usuario, as como tambin con servicios basados en Internet, lo que
plantea cuestiones sobre descubrimiento, proceso de comunicacin o
traspaso de informacin entre dispositivos, entendimiento compartido
del contexto e identidad del usuario, etc.
Experiencias relacionadas con los entornos remotos
Los entornos remotos son similares a los entornos locales ya que son
espacios en los que los dispositivos recopilan informacin y toman
medidas. Sin embargo, los entornos remotos no se encuentran en la
proximidad inmediata del usuario del dispositivo. En otras palabras, los
escenarios y experiencias que se relacionan con entornos remotos de
usuarios permiten a esas personas conectarse a dispositivos,
monitorear y trabajar con dispositivos desde otras ubicaciones. Los
motivos para hacer esto seran el monitoreo o incluso el control desde
ubicaciones remotas como medida de proteccin contra actividades
delictivas o por otros motivos. Por ejemplo, las personas pueden querer
monitorear de forma remota sus hogares o lugares de trabajo (como
un centro de datos), o incluso a sus familiares (nios o familiares
ancianos). Un ejemplo simple de este tipo de dispositivos es un
intercomunicador para bebs. Las empresas pueden desear monitorear
ubicaciones remotas; existen muchsimos escenarios relacionados con
la logstica que tambin utilizan dispositivos RFID en esta categora
(por ejemplo, para asegurar el pedigr electrnico de los frmacos a
medida que se transportan a travs de una cadena de distribucin para
eliminar las drogas falsas).
Experiencias relacionadas con redes sociales
La figura 3 muestra que los dispositivos mviles se adecuan a las redes
sociales del mismo modo que lo hacen las computadoras personales.
Los usuarios utilizan sus dispositivos para buscar y encontrar personas
y sus contenidos, para coordinar con sus amigos y parientes y para
compartir contenido con otros.
Sin embargo, el alcance y escala de los dispositivos es mucho ms
amplio que el de las computadoras personales, y las interacciones
sociales son ms espontneas (cuando el usuario est en constante
movimiento, siempre tiene a mano la cmara de su telfono celular).
Es necesario que las aplicaciones y los servicios se adapten a estos
escenarios en los que el tiempo de atencin que se le presta al usuario
es claramente limitado.
Arquitecturas necesarias para construir soluciones integrales
que soporten dispositivos
Desafos al generar experiencias ricas en los dispositivos
Existen muchas diferencias entre los dispositivos y las computadoras
personales y sera un error considerar que los dispositivos son
simplemente versiones ms pequeas de una PC. Para generar
experiencias ricas en los dispositivos, los arquitectos de soluciones
deben considerar una cantidad de factores limitantes, muchos ms que
al generar aplicaciones para una computadora personal. Estas
limitaciones incluyen capacidades de hardware de los dispositivos
mismos, tiempos de ejecucin de aplicaciones y sistemas operativos de
los dispositivos, herramientas de desarrollo, preferencias de
conectividad y tambin servicios disponibles que se ejecuten en la
Web. Algunos desafos que se enfrentan al construir experiencias para
los dispositivos son:
1.
A diferencia de las PCs, consideran a los dispositivos como

accesorios: los usuarios llevan los dispositivos consigo y con
frecuencia los ven como expresiones de su estilo de vida o incluso
autoestima personal. El factor de estar al da con la tecnologa, el
diseo moderno y la experiencia del usuario son cruciales.
Implicaciones: Se necesitan capacidades ricas de presentacin y
diseo de dispositivos, tanto para el dispositivo mismo as como
tambin para las aplicaciones que se ejecutan en el dispositivo.
2.
3.
4.
5.
Los dispositivos tienen recursos limitados. A medida que los

dispositivos, y sus bateras, pasan a ser ms pequeos y livianos,
el tamao de las pantallas y la presentacin se restringe ms y la
energa disponible para respaldar aplicaciones ricas disminuye.
Los dispositivos ms sofisticados tienden a tener bateras de
menor vida til que los telfonos simples. Tambin, la capacidad
de la memoria del dispositivo es limitada, si bien esto se mitiga
mediante mejoras en la tecnologa de almacenamiento. El soporte
de los dispositivos para Wi-Fi, por lo general, tambin tiene la
desventaja de una menor vida til de la batera.
Implicaciones: La eficacia de la energa es crucial. Los sistemas
operativos de los dispositivos deben tener un control detallado
sobre la utilizacin del hardware. En algunos casos, el
procesamiento de la aplicacin debe descargarse del dispositivo
para evitar el consumo excesivo de recursos. Esto lleva a una
compensacin entre los dos primeros puntos de esta lista.
Los dispositivos no estn estandarizados. A diferencia de las PCs,
los factores de forma y los perfiles de software/hardware de los
dispositivos estn mucho menos estandarizados.
Implicaciones: Un desarrollador de aplicaciones para dispositivos
mviles debe centrarse en el menor denominador comn en lo
que se refiere a tamao de pantalla, forma y orientacin para
poder implementarlos en una gran variedad de microtelfonos.
Esto da como resultado una compensacin implcita con la
necesidad de experiencia de usuario rica; los arquitectos de
soluciones debern optimizar el software y el hardware para
obtener la experiencia ms completa. Los desarrolladores de
aplicaciones para dispositivos incorporados poseen diferentes
desafos en este rea, la falta de estandarizacin del hardware
dificulta suponer el grupo de recursos que estarn disponibles
para la aplicacin.
Los dispositivos deben soportar escenarios sin conexin y a
veces, conexiones lentas. Por muchos motivos, los dispositivos no
siempre estn conectados (por ejemplo, las conexiones pueden
no ser rentables durante viajes internacionales) o las velocidades
de acceso no son lo suficientemente rpidas como para admitir la
toma de decisiones cuando se necesita (el uso de mapas en lnea
para tomar decisiones sobre rutas mientras se viaja).
Implicaciones: Los dispositivos necesitan ser ms que pantallas
de cliente liviano; deben ser plataformas de aplicacin por s
mismos. Un requisito clave para esta capacidad es el
almacenamiento y procesamiento local, con sincronizacin con
PCs o servicios de Internet.
La conectividad no est estandarizada. Si bien existen diversas
normas para los protocolos de red, tambin existen muchas
formas para que un usuario acceda informacin y servicios en
Internet desde sus dispositivos mviles. En funcin de las
capacidades de su dispositivos y el plan de servicios que tiene con
su operador de red, un usuario puede desear acceder informacin
y servicios en Internet mvil a travs de la voz (mediante el
reconocimiento de voz), mensajera (SMS, correo electrnico) o a
travs de protocolos de Internet (Wi-Fi, conexin relacionada o
plan de datos adecuado). En los mercados emergentes es
probable que los servicios deban ofrecerse sobre SMS o voz ya
que es ms probable que los usuarios tengan telfonos masivos
con capacidades muy limitadas.Para experiencias ricas de

multimedia, es probable que se necesite un protocolo de Internet
rpido.
Implicaciones: Acceso personalizado para el tipo de experiencia
que se entrega y para el mercado al que se ofrece. Es posible que
los servicios necesiten ser accesibles para dispositivos desde una
cantidad de puntos finales diferentes, cada uno con soporte para
un mtodo de acceso y direccin diferente.
Aplicacin de un enfoque de Software + Servicios para
dispositivos
La ltima edicin de The Architecture Journal trat el paradigma
emergente de Software + Servicios. En el contexto de una aplicacin
mvil, el objetivo es combinar lo mejor de la Web con los mejores
aspectos de los dispositivos, pero sujeto a las limitaciones que se
acaban de describir. Como se muestra en la Figura 4, los arquitectos de
soluciones deben disear para un tipo especfico de experiencia de
usuario, y seleccionar un dispositivo adecuado que se base en las
capacidades mnimas necesarias para un dispositivo (hardware y
software en el dispositivo) y opciones de conectividad as como
tambin servicios disponibles para los usuarios del dispositivo.
Factores de forma de hardware del dispositivo
Debido a que existe una gran variedad de escenarios basados en la
movilidad, existe tambin una gran variedad de factores de forma de
dispositivos para soportar estos escenarios como se muestra en la
Figura 1. La eleccin de un dispositivo depende del modo en el que se
va a utilizar ese dispositivo.
Por ejemplo, en el espacio del consumidor de dispositivos personales
la variedad de hardware disponible abarca ampliamente desde
dispositivos basados en WM (Windows Mobile) en un extremo, laptops
en el otro y dispositivos UMPC en el medio. Los dispositivos WM por lo
general son telfonos inteligentes o computadoras de bolsillo
(habitualmente con tamaos de pantalla de 5 pulgadas) y las UMPCs
con frecuencia son complementos digitales porttiles (habitualmente
con tamaos de pantalla de 5,6 a 7 pulgadas).
Sensores para recibir informacin desde el entorno inmediato
Los dispositivos pueden recibir informacin desde muchos elementos
sensores diferentes que se detallan en esta seccin. Algunos de estos
sensores ofrecen canales para que los usuarios interacten con el
software que se ejecuta en el dispositivo. Otro sensores en el
dispositivo ofrecen aplicaciones con una vista del contexto actual del
usuario en cualquier momento para que el software se pueda ajustar
segn el caso.
1.
Figura 4: Estructura conceptual para la aplicacin de Software +

Servicios en una red de dispositivos
Comunicaciones
Contenido
Conocimiento
del entorno
Experiencia
de usuario
Dispositivo
o PC
Mensajes
Eventos
Solicitudes /mensajes de control
Canal de
acceso
Servicio
Feedback
Cambios en el entorno
Contenido
o datos
2.
Tecnologas sensibles al tacto. Algunos dispositivos utilizan

tecnologas sensibles al tacto para mejorar la experiencia del
usuario. Los dispositivos ms nuevos usan capacitive touch, que
no requiere presin para registrar el tacto (a diferencia de
resistive touch que se encuentra en los dispositivos ms antiguos
y que con frecuencia requera un lpiz). Los dispositivos con
capacitive touch son ms fciles de usar, ms precisos y ms
receptivos. Las pantallas sensibles al tacto ms antiguas, muchas
veces no eran muy claras a la luz del sol, lo que dificultaba
visualizar multimedia rica, pero las pantallas sensibles al tacto ms
nuevas, normalmente son ms luminosas ya que su superficie no
est recubierta con la capa fina necesaria para los dispositivos
resistentes al tacto. Otro progreso es el multitouch (capacidad de
ingresar datos con ms de un dedo al mismo tiempo), lo que le
permite al usuario cambiar el tamao de una ventana
comprimindola o expandindola con dos dedos sobre la pantalla.
Una objecin comn de los usuarios para las pantallas sensibles al
tacto es la falta de respuesta tctil. Sin embargo, algunos
fabricantes de telfonos estn incorporando la tecnologa de
reaccin tctil creada en los controladores de juegos, por ejemplo,
para producir una leve vibracin cuando se toca suavemente el
teclado virtual de la pantalla sensible al tacto. Esto ser similar a la
respuesta que los usuarios estn acostumbrados a obtener de los
teclados mecnicos tradicionales.
GPS. Varias soluciones de movilidad dependen del conocimiento de
la ubicacin del usuario. Una tcnica comn para que un dispositivo
determine su ubicacin es el GPS (o Sistema de Posicionamiento
3.
4.
5.
6.
Global) que cumple su funcin basado en una red de tres o ms

satlites a la vista, lo que significa que el GPS no se puede
utilizar en espacios cerrados. Algunos servicios en la Web
basados en la localizacin utilizan automticamente informacin
del GPS en el dispositivo (cuando est disponible) para
proporcionar informacin que se filtra mediante la ubicacin de
los usuarios (Live Search).
Acelermetro. Varios dispositivos tienen acelermetros
incorporados. Un uso bsico de esto es detectar automticamente
la orientacin del dispositivo, es decir, horizontal o vertical. Los
usos ms avanzados del acelermetro incluyen el reconocimiento
de gestos, control de multimedia, control de juegos. En el futuro,
es muy probable que los acelermetros en los dispositivos puedan
llevar a escenarios sofisticados de control similares los del control
remoto del Nintendo Wii, que est construido en torno a un
acelermetro.
Sensores de monitoreo para la salud. Algunos ejemplos son los
sensores para controlar el ritmo cardaco o el nivel de azcar en
la sangre.
RFID. Los lectores, escners e impresoras RFID comprenden una
gran variedad de dispositivos que utilizan tecnologas RFID, sobre
todo en escenarios empresariales como logstica o gestin de
cadena de distribucin. Los dispositivos que poseen sensores
RFID incorporados estn hechos para reemplazar una generacin
anterior de dispositivos que utiliza el escaneo de cdigo de
barras.
Otros sensores. Otros sensores que pueden encontrarse en los
dispositivos pueden incluir sensores de luz ambiente (para
controlar el brillo de la pantalla y preservar la vida til de la
batera) o sensores de proximidad (para apagar la pantalla
cuando el dispositivo se utiliza como telfono).
Software ejecutable en el dispositivo

El software que se ejecuta en un dispositivo se incluye dentro de las
siguientes categoras:
1.
2.
3.
4.
Sistema operativo del dispositivo.

Plataforma de aplicacin: comprende el tiempo de ejecucin de
la aplicacin as como tambin herramientas de diseo.
Explorador mvil: esto est evolucionando como una plataforma
de aplicacin por s misma para los dispositivos de consumo.
Aplicaciones.
El sistema operativo se debe seleccionar de acuerdo al uso que se le

dar al dispositivo, ya que existe una compensacin implcita entre el
manejo de recursos de dispositivos limitados y la riqueza de las
aplicaciones que se ejecutan en el dispositivo. Los dispositivos tienen
diferentes necesidades, analicemos las pilas de software para cada
tipo de dispositivo representado en la Figura 1.
Pila de software para dispositivos incorporados. Windows
Embedded CE es un kernel del sistema operativo rgido de memoria
protegida de 32-bits, en tiempo real, que es compatible con una gran

variedad de arquitecturas de procesadores (ARM, MIPS, x86 o SH4).
Viene con un conjunto de casi 700 componentes desde los cuales se
puede empaquetar un subconjunto dentro de imgenes personalizadas.
Por ejemplo, se puede ensamblar una imagen kernel que arranque con
una huella de aproximadamente 300KB, pero tambin es posible aadir
otras tecnologas dentro de la imagen como servidor de Web,
explorador, reproductor de multimedia, soporte para conexin en red,
.NET Compact Framework todos los que aumentan el tamao de la
imagen SO. Los dispositivos que se construyen con Windows Embedded
CE pueden no tener perifricos o tal vez tengan algn tipo de pantalla.
Tambin los dispositivos pueden ser abiertos (es decir, exponen APIs
de aplicacin) o cerrados (sin posibilidad de incorporar capas de
desarrolladores terceros).
Windows CE est disponible para la comunidad general de desarrollo
de sistemas incrustados para que construyan sus propios dispositivos.
Tambin se utiliza dentro de Microsoft para construir las soluciones
Windows Mobile y Windows Auto. Windows Mobile se utiliza para
suministrar energa a telfonos inteligentes y PDAs, mientras que
Microsoft Auto es una plataforma que la industria de los automviles
utiliza para construir soluciones avanzadas en los vehculos.
Pila de software para telfonos inteligentes y PDAs. Windows
Mobile elige su propio conjunto de componentes de sistema operativo
de Windows Embedded CE, con un shell personalizado, tecnologas
especficas para dispositivos (Connection Manager) y algunas
aplicaciones (Office Mobile). Los Windows Mobile OEMs muchas veces
aaden sus propios servicios y aplicaciones especficas a la imagen
(complementos de pantallas, aplicaciones como VoIP, juegos), pero no
personalizan el conjunto de componentes en la imagen base WM. El
resultado es un conjunto de APIs uniformes que se ofrecen en todos los
dispositivos de Windows Mobile: En teora, las aplicaciones que se
escriben para un dispositivo de Windows Mobile deben funcionar en
todos los dispositivos de Windows Mobile. En realidad, los dispositivos
mviles varan mucho en sus capacidades de hardware (opciones de
conectividad, tamao de la pantalla, resolucin, orientacin), lo que
dificulta construir una aplicacin que funcione bien en todos los
dispositivos, incluso, cuando las APIs bsicas son las mismas. La Figura
5 muestra la variedad de opciones de desarrollo para la creacin de
interfaces de aplicacin en un telfono inteligente de Windows Mobile.
Pila de software para PCs Ultra-Mviles. Los dispositivos UMPC
logran la mxima fidelidad de la pila de software: el sistema operativo
de Windows Vista, el .NET Framework como el tiempo de ejecucin
para aplicaciones administradas y el IE7 como el explorador. Las
aplicaciones de PC existentes no necesitan ser escritas para que se
ejecuten en una UMPC, aunque pueden extenderse para que admitan
tacto y tinta (estas capacidades se construyen en la actualidad
exactamente dentro de Windows Vista). Sin embargo, todo esto a
expensas de la vida til de la batera (muchas veces dura slo 4-6
horas), ya que las UMPCs no administran recursos de dispositivos en
un nivel granular del modo que lo hace Windows Mobile.
Figura 5: Opciones de desarrollo para la construccin de interfaces de aplicacin en un

telfono inteligente de Windows Mobile
Experiencias de cliente
inteligente
Experiencias
ricas
interactivas
Formularios
inteligentes
Experiencia rica
Nativo
Administrado
Win32 APIs
(subconjunto de
desktop
Win32 APIs)
.Net Compact
Framework &
SQL
Compact Edition
Formularios
bsicos
Amplio alcance
Ajax
Silverlight
(disponible para
dispositivos en
2008)
AJAX/
Atlas
HTML
Pocket IE
ASP.NET
WAP
Pocket IE
ASP.NET
Controles mviles de
ASP.Net
Canales de acceso para dar soporte a los

dispositivos.
Los dispositivos mviles como los telfonos
celulares se utilizan principalmente para las
comunicaciones, en la actualidad, en su mayor
parte para llamadas de voz, pero tambin para
algn otro tipo de mensajera, como correos
electrnicos, mensajes instantneos (MI) y SMS.
Ms all de estos servicios de comunicacin bsica,
se espera que en el futuro los dispositivos
conecten un grupo de servicios de aplicaciones
mucho ms rico. Si bien existe un mercado
relativamente amplio para esos servicios, no se
dar por hecho que los usuarios de esos servicios siempre
tendrn dispositivos avanzados compatibles con Internet que
tengan ya sea un plan de transmisin de datos o que sean
accesibles mediante WiFi. Esto lleva a la provisin de servicios
para dispositivos a travs de otros canales tambin, como SMS o
voz, al igual que los servicios basados en SMS para pagos
mviles en Kenia que se analizaron anteriormente.
Algunos ejemplos de canales de red sobre los cuales se podran
entregar servicios y aplicaciones son:
1. Voz
a. Reconocimiento de voz: Estos servicios se pueden acceder
mediante una llamada telefnica, con software de
reconocimiento de voz que se ejecuta sobre el otro extremo.
La Figura 6 muestra la forma en la que se puede utilizar
Microsoft Communications Server para brindar aplicaciones
que permiten conversaciones accesibles ya sea mediante
servicios de aplicacin telefnica o mediante canales
alternativos.
Como ejemplo de ese tipo de aplicacin mvil, consideremos
Live Search sobre dispositivos de Windows Mobile que se
pueden acceder mediante una interfaz de voz en los Estados
Unidos de Amrica. El software de reconocimiento de voz
convierte la conversacin de los usuarios en una secuencia
Figura 6: Uso de tecnologas de reconocimiento de voz en Microsoft Office

Communications Server para brindar servicios que permiten el
reconocimiento de voz en Internet.
de consultas para la bsqueda;a continuacin, los resultados se

muestran como de costumbre, para las transiciones y flujos de
pginas (Por ejemplo, Struts).
2. Mensajera
a. SMS: En la actualidad se ofrecen algunos servicios bsicos en
SMS, por ejemplo actualizaciones de inventarios, alertas y, ahora
en algunos pases, bsqueda en Internet. Por ejemplo, Microsoft
Research realiz un proyecto en India en el que construyeron una
solucin para una cooperativa de caa de azcar que permita el
uso de SMS. Los agricultores pueden usar sus telfonos para
obtener informacin, como informacin sobre el precio de mercado,
al enviar sus peticiones como mensajes de SMS. La respuesta a sus
pedidos tambin se les enva como SMS. Microsoft Research ha
puesto a disposicin el juego de herramientas que se utiliz para
este proyecto como una solucin compartida en CodePlex.
(Ver Recursos: SMS Server Toolkit).
3. Internet
a. WiFi: Funciona bien en los dispositivos que estn equipados para
WiFi cuando se encuentran prximos a un punto de acceso a
conexiones inalmbricas.
b. Plan de datos mviles: Por lo general, es un servicio de primera
calidad que se ofrece a travs de operadores de red mviles para
brindar acceso a Internet mediante la red mvil del mismo
operador.
4. Conexin a otros dispositivos con el uso de tecnologas P2P (Punto
a Punto)
a. Algunos dispositivos pueden intercambiar informacin
directamente con otros dispositivos, sin necesidad de que esta
informacin pase a travs de un servidor central. Las
consideraciones de arquitectura, como el descubrimiento y los
protocolos de enlace, se pueden lograr de dos formas:
i. Un servidor de ndice central es intermediario en la conexin:
Por ejemplo, consideremos XBox 360 y XBox Live. Cuando un
usuario se registra en su XBox 360, puede unirse a un grupo de
hasta 16 jugadores que juegan dentro de una nica sesin. Si
bien el servicio de Live mantiene un registro de quienes estn en
lnea e interviene en la conexin inicial del grupo, toda la
mensajera adicional entre las terminales de XBox 360 se
administra mediante tecnologas P2P y no a travs del servidor.
ii. Sin servidor de ndice central: El descubrimiento de dispositivos
cercanos y los protocolos de enlace entre ellos ocurren
directamente, sin pasar a travs de un servidor central. Por
ejemplo, el reproductor de msica Zune puede compartir la
msica que reproduce con otros tres reproductores Zune
cercanos a travs de tecnologas P2P.
Servicios para brindar soporte a dispositivos

Ms all de los servicios bsicos de comunicacin, se espera que en el
futuro los dispositivos se conecten a un conjunto rico de servicios en
Internet. Estos servicios, probablemente, se diseen en tres niveles:
1.
2.
3.
Servicios de aplicaciones y soluciones. Ofrecen servicios especficos

para un grupo de escenarios, por ejemplo, la salud o CRM.
Servicios asociados o de terceros. Son servicios que ofrecen otros
proveedores que se incluyen en los servicios de aplicacin: por
ejemplo, una solucin de movilidad para proveedores de asistencia
mdica que utilizan servicios para correo electrnico,
actualizaciones o colaboracin que a su vez proporcionan terceros.
Servicios de bloques de construccin/infraestructura/utilidades.
Los servicios del segundo y tercer nivel representan capacidades

horizontales comunes que interactan con varios servicios de aplicacin
diferentes. Algunos de ellos se describen a continuacin en el contexto
de soluciones de movilidad. En el futuro, estos servicios, normalmente
los brindar un proveedor de plataforma, como por ejemplo Windows
Live Platforms o incluso, un operador de red mvil.
Seguridad y administracin de dispositivos
Los vectores de ataque para los dispositivos son similares a los de las
computadoras personales en red, excepto que los dispositivos son ms
propensos a robo o prdida, y muchas veces es ms difcil asegurarlos
de forma fsica dada su movilidad (a diferencia de una computadora
que permanece en un escritorio o en un centro de datos). Por lo tanto,
existen tres reas fundamentales en las que se deben considerar los
problemas de seguridad de los dispositivos. La primera es asegurar el
dispositivo mismo. La segunda, asegurar la red, es decir, asegurar la
integridad y confidencialidad de los mensajes. Aqu se podran tratar
una cantidad de asuntos de seguridad en las capas de pilas en red, por
ejemplo, tcnicas de modulacin de radio para brindar seguridad en la
transmisin de seales inalmbricas, IPSec, etc. La tercer rea de
seguridad es asegurar las aplicaciones que se ejecutan en el dispositivo
(o que se ejecutan en la Web pero que se acceden a travs de
dispositivos) que se describe en la seccin de administracin de acceso
e identidad.
En algunos casos, la administracin de los dispositivos es similar a la
de las computadoras personales. Por ejemplo, los dispositivos deben
actualizarse con parches (firmware y software), multimedia o
aplicaciones. Las comunicaciones para los dispositivos deben
asegurarse, y en algunos casos, deben medirse y abonarse (para
descargas comerciales). Sin embargo, la administracin de
dispositivos vara en algunas consideraciones cruciales ya que muchas
veces son ms difciles de asegurar: los dispositivos mviles se
extravan con facilidad, y en varios casos, el acceso a ellos no se
puede restringir.
Se deben brindar servicios de administracin a los dispositivos que
se conectan a una red para poder responder a los siguientes tipos de
preguntas:
Administradores de red: Cuntos dispositivos hay en la red en
este momento? Cunto ancho de banda? Cunto tiempo? Qu
tipos de dispositivos existen?
Mesa de ayuda: Cules son los antecedentes del dispositivo? Se
ha actualizado el dispositivo? Cules son los detalles del
dispositivo?
Administradores de seguridad: Qu dispositivos no tienen la
actualizacin de seguridad? Qu sucedera si implemento esta
poltica? Cuntos dispositivos estn de conformidad?
Usuario: Acabo de perder mi dispositivo y deseara proteger la
informacin privada que hay en l. Podra borrarla de forma
remota?
Cabe observar que cuando se pierde un dispositivo no es suficiente
simplemente restringirlo si ste posee una tarjeta de almacenamiento
de 2GB llena de informacin confidencial. Una forma en la que
Windows Mobile 6 trata este problema es mediante la encriptacin de
los datos de la tarjeta de almacenamiento para que de este modo
slo pueda leerla el dispositivo que la escribi.
Administracin de acceso e identidad
Las aplicaciones que se ejecutan en diferentes dispositivos en red
necesitan un modo de compartir credenciales entre s, as como
tambin con los servicios de fondo a los que se pueden conectar. A
medida que los escenarios para dispositivos se vuelven ms
sofisticados, esto requerir credenciales reconocidas universalmente,
por ejemplo, la identidad del usuario y, en algunos escenarios,
tambin la identidad del dispositivo de origen. En la actualidad, un
telfono celular se identifica mediante un nmero de telfono. Si bien
los telfonos inteligentes permiten que los usuarios se conecten a
servicios de fondo en lnea, esos servicios, normalmente, requieren
que el usuario se autentique de varias formas adicionales, lo que no
tiene nada que ver con el nmero de telfono, por ejemplo, direccin
de correo electrnico u otra credencial basada en la Web. A medida
que los dispositivos proliferen en el futuro, al igual que lo harn los
servicios que los soportan, un identificador nico universal (tal vez,
conceptualmente similar al actual Live ID) podra resolver el problema
de la autenticacin. Sin embargo, surgirn nuevas complicaciones:
Cmo se conecta la identidad entre los dispositivos y los servicios
basados en la Web? En qu punto se establecen los lmites de
confianza?
Si bien se ha hecho mucho para asegurar las redes y dispositivos,
se necesita un grupo de tecnologas diferentes para mediar confianza
entre las aplicaciones que se ejecutan en esas tecnologas de los
dispositivos (y los servicios a los que conectan) para la identidad
federada. Estas tecnologas ayudan al usuario a administrar mltiples
identidades digitales y a controlar la cantidad de informacin personal
que se comparte con otros dispositivos y servicios. Cada una de estas
identidades se construira en torno a un grupo de exigencias que son
expresiones de confianza por parte de un certificador uno o ms
servicios de identidad en la nube que acten como intermediarios de
confianza, emitiendo exigencias (o expresiones de confianza) que se
incrustan en tokens de seguridad.
Punto de encuentro y presencia
Los servicios de presencia mvil hacen que el contexto mvil de los
usuarios est disponible para las redes sociales. Los datos de
contexto, como ubicacin, tiempo de inactividad del dispositivo, perfil
del dispositivo (volumen del sonido, vibrar) e informacin del
calendario estaran disponibles ya sea desde otros dispositivos mviles

o a travs de un aparato/componente/credencial incrustados en el blog
del usuario o en la pgina Web. Podra mostrarse como una lista,
aumentando la lista de contactos, o podra mostrarse en un mapa. En
breve, la presencia mvil deber permitir que la red social de un
usuario conozca cundo se los puede acceder y cundo no y cul es el
modo de comunicacin preferida en ese momento. Esta informacin no
debe ser especfica para el operador mvil del usuario ya que es poco
probable que todos los miembros de la red social del usuario sean
clientes del mismo operador mvil. En el mejor de los casos, esta
informacin de presencia se conectara dentro de una red principal
unificada de comunicaciones que combina diferentes formas de
mensajera.
Servicios basados en la ubicacin
A diferencia de las computadoras personales, es muy probable que en
el futuro la mayora de los dispositivos de consumo conozcan su
ubicacin exacta, posiblemente, a travs de una tecnologa de
determinacin de posicin como GPS. Esto ofrece nuevas posibilidades
para una gran variedad de servicios en la nube que pueden utilizar esa
informacin para presentar el contenido del usuario apropiado para esa
ubicacin. El crecimiento del Sistema de Informacin Geogrfica (GIS)
en lnea con interfaces que se publican para almacenar datos y
metadatos espaciales asociados permite que esta tendencia sea
posible. Algunos de estos sistemas tambin estn codificados con
contenido extra que genera el usuario etiquetado por ubicacin. Un
servicio que se basa en la ubicacin podra utilizar las coordenadas
geogrficas del usuario como un ndice o un filtro dentro de GIS para
recuperar la informacin correcta. Esos servicios pueden incluir
bsqueda local, exploracin, servicios de emergencia, rastreo de nios/
mascotas/objetos de valor, juegos mviles para varios jugadores,
ubicacin de personas en redes sociales, gestin de transporte/
logstica, etc.
Servicios de publicidad y bsqueda mvil
En algunos sentidos, la bsqueda en la Web desde un dispositivo mvil
no es muy diferente a la bsqueda en la Web desde una computadora
personal. Un anlisis de los registros de bsqueda en Google
presentado en Deciphering Trends in Mobile Search (Descifrar
tendencias en la bsqueda mvil) muestra que a pesar de las
limitaciones en las tcnicas de ingreso de datos, la cantidad de
palabras promedio en un pedido de bsqueda no cambia mucho entre
los telfonos mviles, PDAs y las computadoras personales. (Ver
Recursos: Deciphering Trends in Mobile Search).
Sin embargo, en otros sentidos, la bsqueda mvil tiene la
posibilidad de ser ms dinmica que la bsqueda desde una
computadora personal. Los dispositivos pueden conocer ms sobre el
contenido actual de los usuarios (ubicacin). En la actualidad, los
motores de bsqueda procesan consultas en un ndice que se ha
construido mediante la exploracin minuciosa de la Web. El potencial
de la bsqueda mvil es que el contenido extra disponible para el
dispositivo podra tambin utilizarse a travs del motor de bsqueda
cuando se formula su respuesta. Por ejemplo, se pueden filtrar los
resultados de una bsqueda por ubicacin actual o la lista de enlaces
patrocinados podra incluir un cupn mvil para un comercio local.
Como ejemplo de esto, Live Search para Windows Mobile ahora
incluye el ingreso de datos por voz (beta), precios del combustible y
horario de operacin de los comercios. El servicio tambin puede
utilizar datos del GPS en telfonos compatibles con GPS para brindar
una bsqueda local con conocimiento de la ubicacin.
Servicios de gestin de contenido, entrega de contenido y
almacenamiento
Como se mencion en la seccin sobre tendencias sociales, la
proliferacin de los dispositivos est produciendo una explosin en la
cantidad de contenido que se genera y que debe almacenarse fuera del
dispositivo. Esto genera la necesidad de que los servicios de
almacenamiento realicen una copia de seguridad de los dispositivos,
Figura 7: Resumen de las opciones de desarrollo para la construccin de soluciones mviles
Resumen
En la Figura 7 se muestra una vista resumida de
todas las opciones de desarrollo disponibles para
un arquitecto de soluciones de movilidad, junto
con ejemplos de experiencias especficas, puntos
de conexin y canales de acceso. Existen varias
consideraciones comunes para las tecnologas de
acceso, servicios y dispositivos, por ejemplo, el
modo de administrar la identidad y la confianza
a travs de todos estos niveles diferentes.
El enfoque de un arquitecto de soluciones de
movilidad debe ser equilibrar la necesidad de
lograr amplio alcance y escala para su pblico
objetivo y la necesidad de entregar experiencias
ricas con las cuales se puedan conectar los
usuarios. Las soluciones ideales combinarn lo
mejor de la Web con los mejores aspectos de los
dispositivos.
Recursos
Deciphering Trends In Mobile Search
http://www.maryamkamvar.com/publications/
KamvarBalujaComputerMagazine.pdf
Mobile Phones As Mass Media: Models For
Content Distribution, por Alan Moore
http://www.masternewmedia.org/media/
mobilephones/mobile-phones-as-mass-mediawhite-paperpart-2-20070711.htm
que las redes de entrega de contenido trasladen los datos y tambin

que los servicios de gestin de contenido organicen el contenido
recientemente adquirido para que se pueda encontrar.
La organizacin del contenido conlleva una taxonoma, que podra
estar explcitamente definida pero es ms probable que surja basada
en el etiquetado del contenido con una captura de imagen del
contexto del usuario en el momento que se cre el contenido. Este
contexto podra ser ubicacin, tiempo, un evento, etc., cualquier cosa
que el dispositivo haya conocido y registrado automticamente.
Servicios de alerta
Debido a que la cantidad de contenido disponible en lnea contina
creciendo, es necesario que los usuarios filtren las seales de
informacin que reciben. Una forma en la que los usuarios podran
hacer esto es mediante la suscripcin a un servicio particular de
alertas como Windows Live Alerts. Estas alertas se pueden recibir en
los dispositivos mviles como mensajes SMS. El usuario tambin
puede incrustar un mecanismo para leer alertas en su propio sitio
Web.
Servicios de sincronizacin
A medida que los usuarios pasan al mundo de dispositivos, el
contenido se deja cada vez ms disperso en las computadoras
personales del hogar, de la oficina, en servicios en lnea y ahora en
telfonos mviles. Una parte importante de las soluciones de
movilidad integrales incluirn servicios de sincronizacin, lo que
resuelve el problema de sincronizar cualquier tipo de contenido, sobre
cualquier protocolo y sobre cualquier dispositivo o computadora
personal. Estos servicios de sincronizacin debern poder tratar
problemas sutiles sobre escenarios que requieren almacenamiento en
cach, uso sin conexin, intercambio y roaming. Una forma de
construir esos servicios es utilizar el Sync Framework de Microsoft,
que le permite a los desarrolladores de aplicaciones aadir con
facilidad capacidades de sincronizacin en una aplicacin o servicio.
Esto es posible a travs de un modelo de proveedor que pueda
extenderse para admitir escenarios comunes como sincronizacin de
bases de datos relacionales, sistemas de archivos, listas, dispositivos,
PIM, msica, video, etc.
Safaricom: On a Tear in Africa por Jack Ewing, 27 de agosto de 2007,

BusinessWeek
http://www.businessweek.com/globalbiz/content/aug2007/
gb20070827_543072.htm
SMS Server Toolkit
http://research.microsoft.com/research/downloads/details/
9190f48f-6e3d-4ee8-b4a9-b346db76be1d/details.aspx
Upwardly Mobile in Africa por Jack Ewing, 13 de septiembre de 2007,
BusinessWeek
http://www.businessweek.com/globalbiz/content/sep2007/
gb20070913_705733.htm
Sobre el autor
Atanu Banerjee es miembro del equipo Arquitectura de Plataforma en
Microsoft, donde trabaja sobre arquitectura para soluciones de la
prxima generacin. Se uni a Microsoft desde i2 Technologies donde
trabaj en varios roles por ms de siete aos, que incluyen arquitecto
en jefe para una lnea de productos de gestin de cadena de
suministro, gerente de desarrollo, arquitecto de producto, lder de
equipo y desarrollador de software. Durante ese tiempo, escribi
mucho cdigo, dise nuevas soluciones y trabaj con algunos grandes
clientes de fabricacin. Antes de i2, Atanu trabaj en el grupo de
sistemas de control avanzado en Aspen Technologies, donde dise e
implement sistemas de control de modelo predictivo para la industria
de procesos. Atanu obtuvo su Ph.D. en Georgia Tech en 1996. Reside
en Redmond, Wash, con su esposa y su hijo de seis aos.
Mejores prcticas:
extensin de aplicaciones
empresariales para
dispositivos mviles
Por Kulathumani Hariharan
Sntesis
La extensin de aplicaciones empresariales para dispositivos
mviles se est volviendo cada vez ms una prioridad para
las organizaciones que optimizan su fuerza laboral. Para
lograr el resultado deseado de una solucin mvil robusta,
escalable, segura y eficaz con soporte mltiple para
plataformas de dispositivos, se deben unir varios
componentes. El desafo es extender de forma homognea
varios tipos de aplicaciones empresariales, muchas basadas
en una variedad de tecnologas y plataformas, hacia los
dispositivos mviles. Este artculo describe en lneas
generales los componentes necesarios para extender una
aplicacin empresarial genrica hacia los dispositivos
mviles, trata algunas mejores prcticas y recomendaciones
y describe el estudio de un caso basado en una
implementacin del mundo real.
Visin general de soluciones mviles
Al extender soluciones empresariales para dispositivos mviles, varias
soluciones requieren un enfoque de tres niveles: la aplicacin
empresarial en s misma, middleware mvil y la aplicacin cliente
mvil.
Aplicacin empresarial. Existen, por supuesto, varios tipos de
aplicaciones empresariales que se pueden extender hacia los
dispositivos, como Gestin de Relacin con el Cliente (CRM),
Planificacin de Recursos Empresariales (ERP) e Inteligencia
Comercial (BI).
Middleware mvil. Debido a que la mayora de las aplicaciones
empresariales no tienen una forma directa de funcionar con
dispositivos, el middleware mvil (como se lo llamar en este
artculo) cumple una funcin crucial. Algunas de las caractersticas
importantes de este nivel incluyen la seguridad, sincronizacin de
datos, administracin de dispositivos y el soporte necesario para los
mltiples dispositivos.
Aplicacin cliente mvil. La aplicacin cliente mvil es, por
supuesto, el software que se ejecutar en el dispositivo. Existen
varias consideraciones en este nivel, que incluyen la disponibilidad de
datos, comunicacin con el middleware, utilizacin de recursos locales
y almacenamiento local de datos. Adems, deben considerarse varios
factores comerciales. Por ejemplo, Quines son los usuarios
objetivo? En qu medida es importante tener los datos ms
recientes? Existen restricciones para el almacenamiento de datos en
el dispositivo? Qu instrucciones existen en el caso de que no haya
conectividad a la red?
Al seleccionar la plataforma para el dispositivo, observamos tres
opciones esenciales:
Aplicaciones en lnea (tambin conocidas como cliente liviano).
Esto es el software cliente, por lo general un explorador, que se
utiliza cuando se puede garantizar la conectividad.
10
Sin una conexin, la aplicacin mvil no funciona.

Aplicaciones sin conexin (tambin conocidas como cliente
pesado). Es el software cliente que se instala de forma local para
el dispositivo que contiene todos los datos requeridos para la
duracin de la mayora de las operaciones y sincroniza al final de
cada da o en un perodo de tiempo preconfigurado.
Aplicaciones conectadas de forma ocasional (tambin conocidas
como cliente inteligente). Es el software cliente que se instala de
forma local, similar al modelo sin conexin, pero en el que la
aplicacin puede actualizar o refrescar datos en cualquier
momento. La frecuencia con la que se actualizan los datos
depende de la importancia de la aplicacin.
Utilizando como referencia los tres niveles descriptos anteriormente,
analicemos ahora el significado que esto tiene para una
Automatizacin de la Fuerza de Venta/Automatizacin de tareas en
campo (SFA/FFA) basada en el producto.
Extensin de una aplicacin SFA/FFA basada en el producto
hacia un dispositivo mvil
Una aplicacin SFA/FFA basada en el producto es normalmente parte
de una aplicacin CRM o ERP. Es comn que este tipo de
aplicaciones no tenga una solucin existente para dispositivos
mviles. El cliente del lado del servidor de la aplicacin es por lo
general una aplicacin cliente rica o basada en la Web, respaldada
por una base de datos relacional con un gran abastecimiento de
almacenamiento de datos para toda la organizacin. Tiende a existir
una cierta restriccin sobre el acceso a esta base de datos, que
incluye los siguientes desafos:
Cambios en el esquema para brindar soporte a la extensin
mvil con frecuencia, muy poco se puede hacer (o se debe
hacer) para cambiar el esquema y brindar soporte a las
aplicaciones mviles.
Acceso a datos directamente desde la base de datos y
actualizacin dentro de tablas desde el dispositivo mvil con
frecuencia hay muchos niveles de comunicacin que se deben
atravesar y no es posible acceder a la base de datos directamente
desde el dispositivo.
Comprensin del esquema del almacenamiento de datos los
esquemas para estos tipos de aplicaciones se disean para ser
extendidos y como consecuencia pueden ser de gran extensin y
difciles de manejar.
Diseo de un rea de representacin con una estructura de
esquema similar a la del servidor para que los datos fluyan hacia
los dispositivos mviles crear un entorno de rplica para el
desarrollo y representacin puede ser un desafo.
Presentacin de la solucin
Al extender una aplicacin SFA/FFA basada en el producto hacia
dispositivos mviles, se deben tratar de forma eficaz los desafos
mencionado en la seccin anterior. Para tratar estos desafos la
arquitectura debe considerar componentes que funcionen
conjuntamente.
Extensin de aplicaciones empresariales

La Figura 1 muestra un modelo propuesto para las aplicaciones de
cliente inteligente; la Tabla 1 enumera los componentes para el
middleware y para la aplicacin cliente junto con una breve
descripcin de su rol como parte de la solucin. Cabe observar que la
lista de componentes representa un superconjunto opcional y las
implementaciones especficas pueden no tener todos los
componentes.
Mejores prcticas
A partir de la experiencia, hemos descubierto que las siguientes
resultan ser mejores prcticas al crear aplicaciones basadas en el
modelo que se describe en la Figura 1 y la Tabla 1.
1. Utilizar procedimientos almacenados de bases de datos para
escribir cdigo empaquetador para el acceso a datos ms rpido.
2. Para los datos ad-hoc, los datos se deben introducir mediante
vistas de bases de datos para que tengan salida ms rpida hacia
el dispositivo.
3. La infraestructura de la base de datos intermedia podra ser parte
del servidor central de la base de datos para obtener respuesta
ms rpida hacia los dispositivos mviles (el beneficio depende de
la cantidad de usuarios y la carga del servidor en cualquier
momento).
4. Al extender datos desde el servidor hacia la base de datos
intermedia, se deben incluir slo aquellas columnas y campos que
se necesitan en el dispositivo ya que lo mismo ser extendido en el
dispositivo. Esto ayudar a cumplir las restricciones de tamao en
el dispositivo.
5. La base de datos intermedia slo debe contener datos por un
perodo de tiempo limitado (por ejemplo, dos meses) con archivos
regulares programados; limitar el tamao de la base de datos
reducir el tiempo de bsqueda.
6. Utilizar el nmero de registro de versin para realizar con facilidad
un seguimiento de los registros en las actualizaciones delta durante
la sincronizacin.
7. Utilizar tablas de asignacin en la base de datos intermedia para
realizar un seguimiento del registro de versin y de este modo
facilitar la resolucin de conflictos; por ejemplo, para establecer
una norma sobre conflictos, pasar por alto el registro de una
transaccin mediante un cambio en el lado del servidor, incluso
cuando se realizan varios cambios del lado del cliente. (Una tabla
de asignacin es una tabla en la base de datos intermedia que
contiene la clave primaria de la tabla de la base de datos del
8.
9.
10.
11.
12.
13.
14.
15.
servidor y la clave primaria del registro de la base de datos del

dispositivo).
El servicio de intercambio de datos debe ser un proceso peridico y
debe poder configurarse en la consola de middleware para tratar
los continuos cambios en el sistema del servidor y la base de datos
intermedia (activada desde el cliente), lo que permite crear un
mtodo de trabajo asncrono.
Mantener en el middleware slo los datos necesarios del usuario y
crear un enlace hacia el servicio de directorio de la empresa para la
autenticacin y otros datos del usuario. Esto reducir los problemas
de desactualizacin de la informacin del usuario entre el directorio
de la empresa y el middleware.
No almacenar contraseas en la base de datos intermedia; en
cambio, consulte el servicio de directorio de la empresa durante la
autenticacin. Esto elimina los problemas de desactualizacin que
provoca la falta de actualizacin de la contrasea del lado del
servidor en el middleware.
Durante la sincronizacin, la aplicacin de cliente primero debe
verificar las actualizaciones de la aplicacin mediante el envo de su
versin actual y descarga de la ltima versin, si es necesario; esto
es un mecanismo optimizado para la administracin de versin de
la aplicacin.
Almacenar el perfil del dispositivo del usuario (plataformas del
dispositivo y versiones SO) en la base de datos del usuario y
transferir actualizaciones de versin hacia el dispositivo, segn sea
el caso, mediante el envo de diferentes versiones a diferentes
usuarios.
Conservar tres tablas: cola de entrada, cola de salida y cola de
salida relacionada con el usuario para la administracin de la
sincronizacin, lo que permite simplificar la administracin de colas
y optimizar el proceso de sincronizacin.
Se puede crear un administrador de comunicaciones para probar
tipos alternativos de conectividad cuando el mtodo primario no
est disponible, y de este modo utilizar la opcin de conectividad a
red disponible ms eficaz. Por ejemplo, cuando la LAN inalmbrica
no est disponible, la aplicacin prueba la red General Packet Radio
Service (GPRS); si GPRS no est disponible, entonces el cliente no
podr sincronizar.
El intervalo de sincronizacin de fondo debe considerar la cantidad
de usuarios y la cantidad de usuarios simultneos que puede
soportar el servidor. Estas consideraciones ayudarn a reducir la
carga en el servidor, lo que permitir admitir la mayor cantidad de
usuarios mviles.
Figura 1: Componentes para la extensin de SFA/FFA basados en el producto hacia dispositivos mviles Enfoque de cliente inteligente
11

16. El administrador de sincronizacin del dispositivo slo debe enviar
el nombre de usuario, versin de la aplicacin del dispositivo,
tiempo de intervalo de la sincronizacin y las actualizaciones
delta durante la sincronizacin. Para disminuir la cantidad de
sincronizaciones simultneas, el middleware debe informar si hay
una actualizacin disponible y si es necesaria la actualizacin,
debe informar la prxima vez que se sincronizar,.
17. La columna de estado de registros se debe mantener en el nivel
de registros para componer datos de forma ms rpida durante la
sincronizacin.
18. Las aplicaciones deben disearse de modo que si la energa de la

batera es baja, la prioridad del subproceso de fondo deba
configurarse en baja, lo que permite disminuir el uso del CPU y
aumentar la vida til de la batera.
19. Desarrollar el emulador, si es que no est disponible, para el tipo
de dispositivo. Esto disminuye los esfuerzos durante las fases de
prueba y desarrollo. Por ejemplo, utilizar el asistente de plataforma
de Microsoft para desarrollar un emulador de Win CE que pueda
admitir caractersticas requeridas por la aplicacin.
20. Durante el desarrollo de la aplicacin, tambin desarrollar
Tabla 1: Componentes del middleware y aplicacin cliente
Middleware
Componente
Administrador de acceso a
datos del servidor
Administrador de solicitudes
de datos ad-hoc
Gestin de base de datos
intermedia
Administrador de conflictos
Servicio de intercambio de
datos
Consola del middleware

Servicio de utilidades
especficas
Administracin del usuario

Administracin del dispositivo
Optimizacin de datos
Administrador de seguridad
Servicio de sincronizacin
Servicio de autenticacin
Administrador de conexin
12
Descripcin
Est compuesto de cdigo empaquetador para realizar llamadas a las APIs del servidor e insertar,
actualizar o eliminar datos desde el servidor.
Mtodos preconfigurados que devuelven datos ad-hoc en tiempo real al dispositivo mvil.
Administra los datos en la base de datos intermedia
Almacena rplicas de todas las tablas de transaccin con datos y columnas especficas de los usuarios
mviles
Maneja el archivo de datos
Maneja la cola de entrada y la cola de salida
Depura espacio en la base de datos.
Administra conflictos de datos durante la sincronizacin con la base de datos del servidor
Monitorea los conflictos como Server Wins vs. Client Wins, el uso compartido de datos por parte de
usuarios mltiples, la actualizacin de un registro en el dispositivo cuando se ha detectado un registro en
el servidor, etc.
Realiza cambios para un usuario particular desde el servidor para que sean enviados al dispositivo mvil
Aplica los cambios desde el dispositivo mvil hacia el servidor mediante el uso del Administrador de Acceso
a Datos del Servidor
Ejecuta un servicio recursivo de forma regular despus de un perodo de tiempo (configurable)
Enva datos compuestos hacia la cola de salida
Selecciona datos desde la cola de entrada para aplicarlos al servidor.
Interfaz de usuario para configurar el middleware
Se utiliza para configurar mdulos como administracin de usuario, creacin de subconjuntos de datos,
administracin de la sincronizacin, administracin de dispositivos, etc.
Contiene lgica de negocios para realizar actividades especficas que no son parte fundamental del
middleware sino parte de la solucin mvil, por ejemplo, un servicio basado en la localizacin que obtiene
actualizaciones de localizacin que se capturan desde el dispositivo y utiliza un sistema de informacin
geogrfica para asignar latitud y longitud y mostrarlos como informes.
Opcional, de acuerdo a los requisitos comerciales.
Administra a los usuarios mviles que utilizan los dispositivos mviles
La lista de usuarios se puede enlazar con los servicios de directorio de la empresa para utilizar la misma
autenticacin en el dispositivo mvil.
Administra el dispositivo desde el servidor
Enva actualizaciones nuevas de la aplicacin hacia los dispositivos mviles
Visualiza los registros de la aplicacin
Analiza problemas relacionados con el dispositivo
Controla el cumplimiento de las polticas de seguridad de la empresa como eliminar datos en el dispositivo
que no han sido sincronizados por una cantidad determinada de das.
Optimiza el modo en se envan los datos al dispositivo mvil
Comprime datos y selecciona el mejor mtodo para el envo de datos de acuerdo a la velocidad de la
conexin o el tipo de conectividad
Descomprime datos entrantes desde el dispositivo mvil.
Codifica los datos que se envan al dispositivo mvil
Decodifica los datos que se reciben desde el dispositivo mvil.
Componente fundamental del middleware
Los datos que entran desde el dispositivo mvil se reciben en la cola de entrada y los datos que salen se
transfieren al dispositivo mvil desde la cola de salida
El servicio de intercambio de datos compone cambios para un usuario particular en la cola de salida y
aplica los cambios de cola de entrada del dispositivo mvil en el servidor
Sincronizacin de fondo desde el dispositivo; el servicio mantiene la cola relacionada con el usuario y
verifica los nuevos registros que se enviarn al dispositivo mvil.
Autentica al usuario mvil durante el proceso de inicio de sesin y la sincronizacin.
Maneja mltiples conexiones al mismo tiempo desde los usuarios mviles hasta una cantidad mxima de
usuarios simultneos.

aplicaciones de simulacin para evaluar los datos que ingresan y
los datos que salen mediante componentes perifricos
incorporados al dispositivo.
21. La informacin de prueba que se obtiene del fabricante del
dispositivo o que se crea mediante el uso de los manuales del
dispositivo ser crucial para la aplicacin de simulacin.
22. Cuando se disean mdulos para los componentes perifricos, se
deben colocar las funciones especficas de la aplicacin y
especficas del hardware en sus respectivas bibliotecas para que
los cambios que se realicen en los componentes perifricos no
afecten la biblioteca de la aplicacin.
23. Para los casos en los que la aplicacin est compuesta de mltiples
pantallas que tienen funcionalidad y partes de IU comunes, se debe
disear un formulario de base que contenga los elementos
comunes.
24. Siempre que sea posible, utilizar marcos en vez de formularios
mltiples para agilizar la respuesta de la interfaz del usuario.
25. Los mensajes, como alertas y mensajes de error, deben
configurarse en el middleware y deben pasarse al dispositivo.
Cualquier otro archivo de configuracin tambin debe ser
configurable en el middleware y a continuacin, se debe transferir
Aplicacin cliente (Cont.)

Componente
Administrador de
comunicaciones
Administrador de
sincronizacin del dispositivo
Optimizacin de datos
Descripcin
Establece la conexin con la red
Programador para la
sincronizacin de fondo
Acceso a datos remoto
Administrador de la base de
datos local
Administrador de seguridad
Aplicacin / Composicin
Sincronizacin activada por la

actividad de la aplicacin
Lgica de negocios de la
aplicacin
Validaciones y alertas
Interfaz de hardware externo
Administracin de recursos del

dispositivo
Interfaz de usuario
Autenticacin
Autentica con el servicio de autenticacin

Enva y recibe datos desde el servicio de sincronizacin en el middleware
Descarga actualizaciones de la aplicacin y comandos de administracin del dispositivo.
Optimiza la forma en la que los datos se envan al middleware
Comprime datos y selecciona el mejor mtodo para el envo de datos de acuerdo a la velocidad de la
conexin o el tipo de conectividad
Descomprime datos entrantes desde el middleware.
Codifica los datos que se envan al middleware
Decodifica los datos que se reciben del middleware.
Aplica los datos entrantes
Compone cambios para que se enven al servidor.
El componente configurable planifica la sincronizacin de fondo desde el dispositivo mvil
Enva datos hacia el servidor en un intervalo preconfigurado sin la intervencin del usuario,
automticamente.
Realiza llamadas a mtodos definidos en el Administrador de solicitud de datos ad-hoc para tener en el
dispositivo mvil datos en tiempo real; si la conectividad no est disponible, se utilizan los datos existentes
en el dispositivo.
Administra los datos en la base de datos del dispositivo
Aplica y compone datos
Depura los datos temporarios desde la base de datos
Administra el estado de los registros
Administra los detalles de configuracin del dispositivo.
Ejecuta comandos desde el middleware
Aplica las actualizaciones de la aplicacin
Bloquea la aplicacin si el usuario ingresa una contrasea invlida una cantidad determinada de veces
Enva registros al middleware.
Activa la sincronizacin al finalizar un flujo de negocio completo, lo que permite asegurar que est en
sincrona con el servidor del cliente mvil.
Elemento fundamental de toda la solucin mvil (aplicacin real que utilizan los usuarios mviles)
Valida el ingreso de datos del usuario con algunas reglas comerciales

En caso de incumplimiento, muestra alertas en la interfaz de usuario como consecuencia.
Interacta con las interfaces del hardware externo conectadas al dispositivo.
Necesaria para el flujo de datos hacia aplicaciones externas, como por ejemplo el lector de cdigo de
barras.
Accede al estado de los recursos y muestra alertas si se necesita la atencin del usuario.
Aspecto de la solucin mvil
La informacin que ingresa el usuario a travs de IU se valida y procesa mediante lgica de negocios.
Autentica al usuario con el middleware si existe conectividad a la red, de lo contrario, lo autentica con
credenciales disponibles de forma local.
13

a la aplicacin del dispositivo para su uso.
26. Las consultas especficas de la base de datos no
deben estar codificadas de forma rgida, por el
contrario, las consultas deben buscarse desde el
middleware a travs de un archivo de
configuracin.
Figura 2: Diagrama de implementacin de un sistema de gestin territorial en

dispositivos porttiles
Estudio de un caso tcnico: Extensin de una

aplicacin CRM hacia dispositivos mviles para
un Sistema de Gestin Territorial
Una compaa farmacutica principal con presencia en
toda India quera mejorar la eficiencia de sus
Representantes de Ventas que trabajaban en el
campo. Los representantes de venta de la compaa
se reunan con mdicos de clnicas y hospitales para
promocionar las drogas de la compaa, distribuir
muestras y material de promocin y al final del da,
registraban todos los detalles mediante una aplicacin
CRM basada en la Web.
La solucin propuesta basada en lo porttil, tena
los siguientes objetivos:
Mejorar la eficiencia y eficacia de los representantes
de ventas
Mejorar el 10% de la productividad
Reducir los costos del proceso manual como papelera y telfono
Brindar una interfaz de usuario fcil y rpida para lograr la
adopcin exitosa del usuario
Cargar los datos ms reciente desde el dispositivo hacia el servidor
para que los gerentes puedan seguir el trabajo de los
representantes de ventas
Descargar el inventario de productos ms reciente en el dispositivo
para poder vender a los qumicos (slo si existiera conectividad).
Esta solucin basada en lo porttil se dise, desarroll e implement
en toda India donde se encuentra la compaa farmacutica.
Definicin del problema
Los representantes de ventas de la compaa farmacutica realizan
aproximadamente 10 llamadas comerciales para acordar reuniones
con los mdicos y promocionar drogas, tomar pedidos y distribuir
muestras. Una visita del representante, por lo general dura de 2 a 10

minutos ya que los mdicos estn muy ocupados. En este tiempo
limitado, el representante de ventas debe analizar las drogas, obtener
feedback del mdico y distribuir muestras, revistas y material de
promocin. El representante de ventas captura la informacin que
recopilada en papel y al final del da, ingresa toda la informacin
relacionada con las visitas en una aplicacin CRM basada en la Web. El
supervisor del representante de ventas examina todos los datos y
aprueba el trabajo diario; el equipo directivo tambin puede analizar
los datos y visualizar los informes.
Este proceso de captura manual de datos representa varios
problemas. El representante de ventas debe registrar los datos en
papel y debe volver a ingresarlos al final del da en el sistema CRM va
Web. Este proceso produce errores en los datos y discrepancias.
Las desventajas principales del proceso manual existente eran:
Proceso de recopilacin de datos ineficaz
La captura de informacin sobre papel requiere mucho tiempo
Se registran demoras para obtener informacin del campo
Figura 3: Arquitectura de solucin para un sistema de gestin territorial en dispositivos porttiles
14

Tabla 2: Visin general de los componentes del middleware y la aplicacin cliente en la arquitectura de solucin para el estudio de un caso de
sistema de gestin territorial
Middleware
Componente
Administrador de acceso a
datos CRM
Servicio de intercambio de
datos
Administracin del usuario

Consola del middleware
Servicio de sincronizacin
Servicio de autenticacin
Descripcin
Realiza las actualizaciones en la base de datos CRM (datos que capturan los representantes de ventas
mientras estn en el campo de operacin).
Compone los cambios (cola de salida) desde el sistema del servidor CRM basado en la divisin en
subconjunto de los datos para cada usuario (como planificacin de reuniones con doctores/qumicos)
Se ejecuta en un intervalo de dos minutos despus de la finalizacin del proceso anterior
Aplica los datos desde la base de datos intermedia (cola de entrada) hacia el sistema de la base de datos
CRM mediante el uso del Administrador de acceso a datos CRM (datos que capturan los representantes de
ventas en el campo de operacin)
Contiene la lista de usuarios enlazados con el servicio de directorio de la empresa
Contiene informacin especfica del usuario como informacin del dispositivo, hora y fecha de la ltima
sincronizacin, estado de bloqueos del dispositivo, etc.
Interfaz de usuario para el middleware
Interfaz de usuario para la administracin del usuario, administracin del dispositivo, visualizacin de
registros de sincronizacin y registros del servicio de intercambio de datos.
Coloca versiones de la aplicacin en una ubicacin compartida predefinida en el middleware
Crea versiones para prestar servicio a los diferentes tipos de dispositivos.
(Cabe observar que el Administrador de Sincronizacin del dispositivo se encarga del componente
correspondiente de la aplicacin cliente)
Coloca los registros entrantes en la cola de entrada
Transfiere los registros salientes de la cola de salida
Administra la cola relacionada con el usuario como una tabla de ndice para verificar si un usuario
particular tiene registros para descargar.
Autentica al usuario mediante la conexin hacia el servicio de directorio de la empresa.
Aplicacin cliente
Componente
Administrador de
comunicaciones
Administrador de
sincronizacin del dispositivo
Acceso a datos remoto
Aplicacin del dispositivo
(Alertas/IU/Autenticacin)
Descripcin
Conecta hacia el middleware para la autenticacin y sincronizacin de datos.
Trata de conectarse con el middleware primero a travs de Microsoft ActiveSync, si no est disponible, se
conecta mediante GPRS/CDMA
Si no hay ninguna conexin disponible, devuelve un mensaje con la explicacin.
Compone los cambios en la base de datos del cliente en formato XML
Aplica los datos entrantes en la base de datos del dispositivo local
Selecciona archivos de actualizacin de la aplicacin cliente desde una ubicacin predefinida en el
middleware si el archivo no est disponible en el dispositivo.
Conecta hacia el middleware para actualizar listas de campaa y reuniones.
Muestra alertas sobre los detalles de campaas, reuniones a las que no se acudi, etc.
Autentica con el middleware si la conectividad est disponible o autentica de forma local si la conectividad
no est disponible.
Demoras en el soporte a la toma de decisiones y consolidacin

Demoras al enviar la ltima informacin al campo de operacin
Se incurre en gastos de papelera, telfono, etc.
Datos insuficientes para hablar con mdicos y qumicos
No hay un historial disponible de visitas con los representantes de
ventas
Factor de error debido al ingreso de datos tardo
No existe conocimiento del estado del inventario para un artculo
en el campo.
Solucin
Debido a que la solucin CRM ya se haba implementado, se
necesitaba una extensin hacia los dispositivos mviles con el mismo
grupo de caractersticas. La aplicacin porttil deba integrarse con el
servidor CRM sin problemas. Esta solucin porttil de base permite
que el representante de ventas capture y transfiera informacin
desde el campo de operacin de forma eficaz. La aplicacin mvil se
ejecuta en el dispositivo porttil que lleva el representante de ventas
cuando est en el campo de operacin y tiene informacin como datos

del cliente, productos, muestras, historial de la visita, programacin de
visitas e inventario del producto. La Figura 2 de la pgina anterior
muestra la solucin mvil que se implement.
La solucin posee cuatro componentes principales: aplicacin
porttil, base de datos porttil, middleware y aplicacin CRM.
Aplicacin porttil. Esta aplicacin se ejecuta en los dispositivos de
Windows Mobile y se utiliza para capturar los datos desde el campo de
operacin. La aplicacin tambin posee un componente de
sincronizacin para sincronizar los datos porttiles con la base de datos
del servidor que se encuentra en la oficina.
Base de datos porttil. Es la base de datos que reside en el equipo
porttil. Esta base de datos posee los datos especficos para el
representante de ventas individual que permiten su trabajo fuera de las
oficinas.
Middleware. Este componente que reside en la terminal de la
empresa, se utiliza para sincronizar los datos entre la base de datos de
CRM y el dispositivo mvil. El middleware usa una base de datos
15

intermedia que acta como servidor del dispositivo porttil. A
continuacin, los datos que se encuentran en la base de datos
intermedia se sincronizan con la base de datos del CRM mediante el
uso de APIs nativas, lo que proporciona una integracin homognea.
Aplicacin CRM. Es la base de datos del servidor que almacena la
informacin empresarial. Los datos especficos para cada
representante de ventas se descargan hacia la base de datos
intermedia y a continuacin hacia el dispositivo del representante.
Tambin se cargan los datos actualizados desde la base de datos
porttil, primero hacia la base de datos intermedia y a continuacin
se actualizan en la base de datos CRM.
En la Figura 3 de la pgina 14 se muestra la arquitectura de la
solucin basada en los componentes de nuestro modelo genrico de
cliente inteligente de la Figura 1. La Tabla 2 en la pgina 15 enumera
los componentes para el middleware y la aplicacin cliente con una
breve descripcin de su funcin como parte de la extensin de la
aplicacin CRM hacia el mvil.
La arquitectura y el flujo del proceso se pueden resumir de la
siguiente manera:
Los representantes de ventas poseen dispositivos porttiles que
tienen instaladas aplicaciones mviles.
El representante de ventas crea una programacin semanal
(tambin puede ser diaria o mensual) de las reuniones con los
doctores, aprobada por el supervisor.
El representante se conecta a la red empresarial a travs de GPRS
y descarga en la base de datos porttil datos especficos para el
representante de ventas.
El representante mantiene reuniones con los doctores y captura
informacin de la visita del representante mediante el uso de la
aplicacin mvil. El representante tambin captura, si fuera el
caso, las muestras o material promocional que se le entreg al
mdico.
Los datos se cargan y descargan automticamente sin la
intervencin del usuario; los datos actualizados estn disponibles
para el usuario por medio de la sincronizacin de fondo.
El representante de ventas incorpora/actualiza la informacin de
los mdicos si se ha contactado a un mdico nuevo o si se ha
modificado la informacin de los mdicos existentes.
El representante de ventas reserva los pedidos de los hospitales y
los qumicos, con ayuda de una vista en tiempo real del estado del
inventario.
Los gastos en los que se incurre al reunirse con mdicos y qumicos
tambin se capturan mediante el uso de la aplicacin mvil.
Los gerentes pueden ver las actividades de los representantes de
ventas a travs del componente de informes. Tambin pueden
crear estrategias y planes de negocio despus de analizar los
datos.
Durante todo el da, el gerente puede realizar un seguimiento de
los patrones de trabajo del representante de ventas y de los datos
ingresados.
Comprensin de la estructura del esquema en el que se almacenan

los datos: Este desafo se abord mediante el estudio detenido de la
documentacin tcnica del CRM y el anlisis de la estructura de la
tabla en la base de datos del sistema CRM para comprender cada
campo y su uso.
Diseo de un rea de ensayo con estructura de esquema similar a la
del sistema CRM del servidor para que los datos se transfieran hacia
los dispositivos mviles: Este desafo se trat al copiar primero la
estructura de la base de datos del servidor CRM hacia la base de
datos intermedia, a continuacin se eliminaron los campos que no se
necesitaban en el dispositivo y por ltimo se cre un servicio de
intercambio de datos para lograr una integracin eficaz con el
sistema del servidor CRM.
LOS REPRESENTANTES DE VENTAS DE LA

COMPAA FARMACUTICA REALIZAN
APROXIMADAMENTE 10 LLAMADAS
COMERCIALES PARA ACORDAR REUNIONES CON
LOS MDICOS Y PROMOCIONAR DROGAS, TOMAR
PEDIDOS Y DISTRIBUIR MUESTRAS. EL
REPRESENTANTE DE VENTAS CAPTURA LA
INFORMACIN QUE RECOPILADA EN PAPEL Y AL
FINAL DEL DA, INGRESA TODA LA
INFORMACIN RELACIONADA CON LAS VISITAS
EN UNA APLICACIN CRM BASADA EN LA WEB.
ESTE PROCESO PRODUCE ERRORES EN LOS
DATOS Y DISCREPANCIAS.
Beneficios
La compaa farmacutica recibi muy bien el sistema de
automatizacin de la fuerza de venta, en especial los 2000
representantes de ventas que son los usuarios objetivo de esta
aplicacin.
La implementacin del sistema llev a un proceso de recopilacin de
datos de campo eficaz y eficiente y mejor la comunicacin entre los
representantes de ventas y la gerencia. Cada uno de los
representantes de ventas desde el campo de operacin y los gerentes
desde la oficina tienen acceso a la informacin que necesitan, datos
actualizados y relevantes para ellos, ya sea al realizar visitas
comerciales o al planificar estrategias de marketing.
Enfrentar desafos claves

Durante el desarrollo, el equipo de diseo experiment varios
desafos. A continuacin se describen los desafos y la forma en la que
los trataron:
Sobre el autor
No se puede realizar ningn esquema de modificacin para admitir
la extensin mvil: Este desafo se abord mediante la creacin de
un rea de ensayo que tena una estructura de esquema similar a
la de la base de datos del servidor CRM.
No se puede actualizar directamente dentro de las tablas desde el
dispositivo mvil: Este desafo se trat a travs de la creacin de
tablas de asignacin y mediante el uso de cdigo empaquetador
para llamar a las APIs del sistema del servidor CRM.
16
Kulathumani Hariharan es arquitecto de soluciones senior que

trabaja con la prctica de tecnologas pervasivas e inalmbricas de los
servicios de consultora de TATA. Se especializa en el diseo de
soluciones empresariales mviles y en la definicin de estrategias de
adopcin de middleware mvil para clientes empresariales mviles.
Experiencia de
consumidor conectada
en automviles
Por Christoph Schittko, Darryl Hogan y Jon Box
Sntesis
Cul es la diferencia entre un vehculo y un pedazo de metal
y cuatro ruedas? Todo depende de las caractersticas. Los
fabricantes constantemente incorporan dispositivos
multimedia ms nuevos, motores ms potentes y asientos
ms blandos, todo con la excusa de mejorar la experiencia
del conductor. Incluso, con todas esas mejoras, los
fabricantes de automviles apenas han empezado a tratar
las capacidades de la infinidad de avances en los servicios y
software que se han dado en los ltimos aos.
Se habl mucho sobre los servicios en la nube y su
aplicacin basada en el consumo de servicios. A pesar de
esto, varios informes y arquitecturas de referencia que
intentan demostrar patrones para el diseo de estos
sistemas, han tomado un enfoque idealista con respecto a la
aplicacin, con frecuencia, mencionan ejemplos simples o
aplican escenarios que no son pragmticos. Este artculo
define una arquitectura de solucin prctica basada en un
escenario con el cual uno se puede encontrar en la vida
diaria. Nuestra intencin es inspirar a los arquitectos a que
usen el mismo enfoque para definir soluciones innovadoras
en los problemas que enfrentan.
La arquitectura de solucin que se define aqu es una
combinacin de servicios reales de plataforma que existen en
la actualidad y de servicios fabricados que ayudan a
completar la solucin. Esta solucin demostrar la aplicacin
de Software + Servicios (S+S) en la arquitectura de
aplicacin mvil como una forma de extender el estilo de
vida digital ms all del escritorio. La seguridad, privacidad y
arquitectura de datos tambin se tratarn ampliamente.
Escenario
La familia Woodson acaba de comprar un automvil nuevo con una
computadora mvil incorporada. Esta PC sirve como sistema de
entretenimiento y gua, pero tambin viene precargada con diversas
aplicaciones de productividad, como por ejemplo, planificacin de
viajes, recordatorios y un administrador de lista. El software que se
carg en la PC del automvil no slo realiza procesamientos de forma
local en el dispositivo sino que tambin aprovecha los servicios de la
nube para mejorar las capacidades del dispositivo y para asegurar
que la informacin que presenta el software est actualizada.
Los Woodson decidieron llevar su auto nuevo para el prximo viaje

largo previsto de la familia. Mary Woodson no slo es la madre sino
que tambin es la coordinadora de los eventos familiares. Mary se
sienta en la computadora de la familia para planificar su aventura y
utiliza una versin basada en la Web de la aplicacin de planificacin de
viajes que se incluy con la computadora incorporada a su automvil.
Mary planifica la ruta que tomarn y hace reservas en hoteles y
restaurantes para las paradas que tendrn durante el viaje. Mary, sin
saber, utiliza un mashup compuesto de una serie de servicios que se
ejecutan en la nube. Toda la informacin pertinente al viaje se
almacena de forma remota en una ubicacin basada en Internet, que
puede acceder slo Mary y las personas designadas.
INTERNET SE ENCUENTRA EN EL COMIENZO DE SU

TRANSFORMACIN PARA CONVERTIRSE EN UNA
PLATAFORMA DE SERVICIOS EN LA NUBE.
PLATAFORMAS COMO WINDOWS LIVE OFRECE APIS
BSICOS PARA LA ADMINISTRACIN DE CALENDARIO,
CONTACTOS, ALERTAS Y PRESENCIA, AS COMO
TAMBIN MAPAS DE VIRTUAL EARTH Y RUTAS; COMO
OTRO EJEMPLO, LOS SERVICIOS DE BIZTALK
OFRECERN UNA PLATAFORMA PUB-SUB
(PUBLICACIN/SUSCRIPCIN) Y TAMBIN ENTREGA Y
ENRUTAMIENTO DE MENSAJES.
Cuando llega el momento de confirmar las reservas de hotel y pagar
los boletos para las atracciones, Mary duda cuando le piden
informacin sobre su tarjeta de crdito. Ella escuch que ingresar
informacin sobre la tarjeta de crdito en un sitio de Web podra
potencialmente causar el robo de identidad. En seguida, se siente
aliviada al descubrir que puede crear y utilizar una tarjeta de
informacin digital administrada por su banco para presentar
informacin de pago a los diferentes proveedores. Esta opcin brinda
una medida de seguridad ya que presenta informacin de su tarjeta de
crdito en Internet a cada uno de estos proveedores de forma
individual. Mary puede seleccionar la tarjeta adecuada desde su
escritorio como una fuente de informacin de pago, lo que permite a su
banco transferir informacin de su tarjeta de crdito asegurada a los
proveedores necesarios sin transmitir informacin confidencial de su
PC.
El viaje se inicia sin demasiados acontecimientos. Los nios han
elegido llevar algunos de sus DVD durante el viaje. Si deciden por
capricho que quieren ver algo diferente a lo que han llevado, siempre
pueden descargar una pelcula al automvil. Para el padre, su telfono
inteligente se conecta slo al auto va Bluetooth y sus llamadas,
mensajes de texto y correos electrnicos ahora se envan a la
computadora del vehculo en vez de a su telfono. Un mensaje de
17
Experiencia de consumidor conectada

Figura 1: Auto PC ofrece aplicaciones para administrar el vehculo y el viaje.
texto entrante desde el sistema de seguridad de la casa indica que

uno de los detectores de movimiento ha detectado movimiento en el
jardn posterior. El padre llama a Bob Thomas, su vecino, para que
verifique la situacin y se entera que slo era uno de los nios de
barrio que estaba buscando su pelota perdida.
A pocas horas del viaje, se enciende la luz del motor.
Inmediatamente se envan datos al servicio de diagnstico que
proporcion el fabricante del vehculo. El servicio encuentra que debe
atender un problema que cubre la garanta y enva un mensaje a la
PC incorporada al auto con un simple informe de diagnstico y el
nombre y ubicacin del concesionario ms cercano a la ubicacin del
auto en ese momento. La madre hace un clic en la direccin del
concesionario para obtener instrucciones paso a paso de cmo llegar
y la familia se dirige hacia el desvo. La familia utiliza la funcionalidad
de bsqueda que se encuentra en la consola de la computadora del
auto para encontrar un restaurante cercano al concesionario y comer
una comida ligera. (La Figura 1 ilustra el escenario de la luz del
motor).
Despus de obtener servicio en el auto, retoman su ruta con un
atraso de tres horas. La madre obtiene el itinerario de viaje que haba
creado en su casa. Deben cancelar la reserva del restaurante que se
encuentra en la prxima ciudad y hacer nuevos planes para la cena.
La madre pide pizza en lnea que retirarn en una pizzera cercana y
realiza el pago una vez ms mediante su tarjeta de informacin
bancaria. Despus de una estupenda comida, todos esperan con
ansiedad un viaje memorable.
Arquitectura de la solucin
Opciones de arquitectura
Como vern en este escenario, la solucin agrupa
servicios de diversos proveedores y aplicaciones que
consumen estos servicios. Las aplicaciones de
consumo podran ser ya sea contenedores de
aplicaciones que siguen los patrones de la interfaz de
usuario (IU) compuesta para permitir el suministro
dinmico de nuevos servicios o podran ser
aplicaciones personalizadas de propsito especfico
que se entregan como aplicaciones cliente. El enfoque
general sigue el
18
paradigma de S+S para brindar una experiencia de usuario simple, e

incluso rica e intuitiva, en todos los dispositivos y destinatarios. La
combinacin de software cliente y servicios remotos es especialmente
importante en este escenario mvil ya que el software que se ejecuta
de forma local puede mejorar la experiencia del usuario enmascarando
las llamadas al servicio en el aire de alta latencia o problemas
temporarios de conexin a red que son comunes, incluso en las
modernas redes inalmbricas de rea amplia.
Los servicios se clasifican en tres categoras generales (Tabla 1):
Servicios de plataforma comn, servicios de consumo que publican
terceros proveedores de servicios. Estos son tipos de servicios que
otros proveedores de servicios toman como base para extender su
nivel, as como tambin para utilizar la madurez y estabilidad de la
infraestructura, especializacin y esfuerzos comerciales de otros.
(Uno de los principios fundamentales de S+S). Muchas empresas en
lnea y de software han hecho realidad la oportunidad de construir
una plataforma en la nube. El ofrecimiento de servicios de
Microsoft bajo la marca Windows Live es un ejemplo para una
plataforma de Internet.
Servicios del fabricante, servicios que brinda el fabricante ya sea en
el vehculo o en la nube para tener acceso a informacin sobre el
vehculo, el concesionario y el fabricante.
Tabla 1: Relacin de categoras del servicio de consumidor conectado para la

taxonoma de servicios de Windown Live
Servicios de experiencia de consumidor
conectada
Categora de servicios de Windows Live
Servicios de plataforma comn
Servicio de bloques de construccin
Servicios del fabricante
Servicios asociados
Servicios de valor agregado
Servicios asociados o servicios finales

Figura 2: Los servicios compuestos RescueMe agregan servicios del
fabricante del automvil y de terceros.
Figura 3: La arquitectura ms flexible slo consume servicios remotos
Servicio de
localizacin
del
concesionario
Servicio
RescueMe
Servicio de
diagnstico
del vehculo
Mapas en vivo
Internet
Servicios de valor agregado, servicios que brinda el fabricante del

automvil o terceros para ofrecer servicios que incrementan las
ventas o la fidelidad de los clientes o servicios que se ofrecen para
brindar apoyo a dispositivos de propsito especfico que venden
terceros.
Estas categoras de servicios mejoran la categora de servicios ms
genrica para los servicios de Windows Live que se enumeran en:
http://www.microsoft.com/online/default.mspx
Entorno tecnolgico (Limitaciones e hiptesis)
La solucin requiere un entorno en el que el acceso a Internet est
ampliamente disponible, pero no necesariamente ubicuo.
Idealmente, el automvil cuenta con los medios para conectarse a
Internet sin dispositivos adicionales, por ejemplo, no necesita un
telfono celular de base para habilitar el acceso a la red para
servicios que proporciona el automvil. El acceso a la red desde el
automvil permite escenarios de aplicacin como inicio remoto,
diagnstico remoto y notificaciones de eventos en el auto.
Algunas aplicaciones que aprovecha la informacin de localizacin
pueden no requerir el contexto que proporcionan los datos
especficos del vehculo. Esas aplicaciones tambin podran
ejecutarse en dispositivos de consumo, como telfonos inteligentes
habilitados para GPS y asistentes digitales personales, ya que no
existe una dependencia sobre los datos especficos del vehculo.
Estos dispositivos por lo general estn equipados con plataformas
modernas como .NET Compact Framework y pueden acceder a
servicios de Web basados en SOAP como un servidor o una
computadora de escritorio. Visual Studio 2008 y .NET Compact
Framework incluyen soporte para el consumo de servicios de Web
basados en WCF y WS-* para la seguridad en el nivel del mensaje y
WS-Addressing que se basan en WS-Security.
Servicios de valor agregado
En nuestro escenario, la familia Woodson experimenta varios tipos
diferentes de software y servicios. Por ejemplo, el fabricante del
vehculo proporcion un servicio para analizar datos de diagnstico
del vehculo y para notificar al propietario del vehculo de algn
problema junto con informacin sobre el lugar en el que puede
solucionar el problema. El servicio de planificacin de viajes
almacen el itinerario de viaje y habilit su acceso desde Internet.
Estos son servicios de valor agregado que se pueden describir de
forma ms completa como servicios que brindan una experiencia
nica al consumidor. Estos servicios son diferentes a los servicios de

plataforma comn ya que no se consideran de propsito general o
ampliamente disponibles. Ms bien, se desarrollan muy probablemente
para establecer un beneficio competitivo o tal vez, para extender la
utilidad de otro producto.
En varios casos, estos servicios pueden ser combinaciones de cdigo
personalizado y uno o ms servicios de plataformas principales, lo que
permite al proveedor del servicio poner a disposicin caractersticas
cuando no tienen conocimiento de dominio especfico. Un ejemplo de
una aplicacin compuesta sera un servicio de localizacin de
concesionarios (Figura 2). Un fabricante de automviles puede conocer
la ubicacin de los concesionarios, pero es poco probable que tuviera
los datos necesarios para brindar orientacin hacia el concesionario en
la navegacin desde una ubicacin especfica. El fabricante muy
probablemente confiara en los servicios que brindan Windows Live
Maps o Mapquest.
Por s solos, los servicios de valor agregado no seran considerados
productos finales. Estos servicios son bloques de construccin de
dominio especfico para construir aplicaciones completas. Podemos
decir que estos servicios brindan las caractersticas que se utilizan para
crear una pieza de software ms compleja y completa.
La mayora de la flexibilidad se obtiene mediante el uso de un
modelo de implementacin que est compuesto nicamente de
servicios que se ejecutan en la nube, ya que los cambios slo requieren
actualizaciones en los servidores que alojan los servicios, no en cada
automvil que consume el servicio. Estos servicios normalmente son
servicios basados en HTTP que pueden invocar los clientes, ya sea una
aplicacin u otro servicio. La ventaja de este enfoque es que todo el
software que se ejecuta se implementa de forma central hacia un
centro de datos lo que facilita su administracin. La desventaja es que
el consumidor del servicio debe tener conexin disponible para utilizar
el servicio (Figura 3).
Si bien es posible ejecutar la solucin completa en el cliente, este
patrn constituye un entorno cerrado en el que el acceso a datos ms
relevantes y actualizados no es posible, lo que hace que la solucin sea
menos til. Este es el diseo que existe en la actualidad para varios
sistemas de informtica mvil, en especial, aquellos que se basan en
automviles. La ruta de actualizacin para estos dispositivos es
inexistente y la funcionalidad limitada que brindan es de beneficio
mnimo para el propietario del dispositivo (Figura 4, pgina 20).
Un patrn preferible para una solucin de informtica mvil se
beneficia de la capacidad de acceder software y datos que se
almacenan en el dispositivo local. En este caso se puede implementar
la lgica de valor agregado en el dispositivo y poner a disposicin en la
aplicacin los suficientes datos para que la aplicacin sea til incluso
cuando la conexin no est disponible. Este modelo descentraliza una
gran cantidad de lgica de control e integracin y presenta desafos de
solucin de fallas y mantenimiento, pero las mejoras en la experiencia
del usuario muy probablemente harn que los esfuerzos valgan la pena
(Figura 5, pgina 20).
19

Figura 4: La arquitectura menos flexible slo consume servicios
locales que ofrece el vehculo
Figura 5: La arquitectura de Software + Servicios combina los

beneficios de servicios locales y remotos.
Plataforma tecnolgica de servicios

Internet se encuentra en el comienzo de su transformacin para
convertirse en una plataforma de servicios en la nube. Plataformas
como Windows Live ofrece APIs bsicos para la administracin de
calendario, contactos, alertas y presencia, as como tambin mapas
de Virtual Earth y rutas; como otro ejemplo, los servicios de BizTalk
ofrecern una plataforma pub-sub (publicacin/suscripcin) y
tambin entrega y enrutamiento de mensajes. Estos son todos
ingredientes claves para aplicaciones conectadas eficaces y ricas,
pero los SLAs y el conjunto de caractersticas actuales refleja que
estos servicios an estn en el comienzo de su ciclo de vida.
Futuros servicios podran extender las configuraciones de presencia
con una configuracin mientras se conduce que siempre permita
alertas de trfico y algunas otras alertas que configure el conductor
el API de alerta podra aadir automvil adems de aplicacin IM,
correo electrnico y SMS en la lista de puntos finales de
notificacin.
Plataforma tecnolgica del cliente mvil

Existen varias plataformas entre las cuales elegir cuando se trata de
hacer realidad la experiencia conectada de consumidor y existen
compensaciones entre las plataformas. Las prioridades y limitaciones
que dicta la solucin real deben orientar la seleccin de la plataforma.
En general, Windows Vista Embedded hace posible la experiencia ms
rica a travs del conjunto de caractersticas del sistema operativo y del
completo .NET Framework, pero tambin es la plataforma que posee la
huella ms grande, los requisitos de procesador ms exigentes y el
costo de licencia de ms alto. Windows CE brinda una alternativa de
costo menor con menos requisitos de hardware y ms opciones para
personalizar el sistema operativo pero menos capacidades. Una
plataforma basada en Windows CE debe incluir .NET Compact
Framework para aprovechar los beneficios de productividad del
desarrollo de cdigo administrado y las bibliotecas de clase base.
Finalmente, Windows Mobile proporciona una experiencia rica en
constante mejora. Los servicios de plataforma se
Tabla 2: Puntos de decisin de plataforma de cliente

Windows Embedded
.NET Framework
Escenario objetivo
Escenario UMPC
Rico en el vehculo
Windows CE .NET Compact

Framework
Windows Mobile .NET Compact

Framework 2.0 (3.5)
Escenario de baja fidelidad en el

vehculo
Dispositivo de consumo
Formularios de Windows
Silverlight en un futuro cercano
Formularios de Windows
Silverlight en un futuro cercano
Servicios de Web WS-I SOAP
WCF Client (3.5)
Complementos de terceros de
reconocimiento de voz
Tacto en dispositivos PocketPC
UX
Conjunto completo de
caractersticas WPF
Comunicaciones
WCF SOAP, REST y JASN
Interaccin
Reconocimiento de voz con Vista

o terceros
Complementos de tacto
Servicios de Web WS-I SOAP

WCF Client (3.5)
Complementos de terceros de
reconocimiento de voz
Tacto si el hardware lo admite
Autenticacin
CardSpace
Nombre del usuario
Certificados
Almacenamiento de
datos
Acceso total a dispositivos de

almacenamiento local y una
variedad de bases de datos
Sistema de archivo local

Opcional SQL CE
Sistema de archivo local

Opcional SQL CE
Herramientas de
desarrollo
Visual Studio
Visual Studio
Visual Studio
Integracin en el
automvil
S, a travs de puertos
personalizados o seriales
S, a travs de puertos personalizados

o seriales
No
20

brindan a travs de una estructura compacta, lo que permite ofrecer
un modelo de programacin consistente junto con las habilidades de
un gran grupo de desarrolladores. La Tabla 2 de la pgina anterior
enumera los puntos fuertes y las limitaciones de cada plataforma
para el desarrollo de aplicaciones mviles.
Aplicacin cliente
En la actualidad existen diversas opciones disponibles para
interactuar con sistemas informticos. Las aplicaciones de cliente
rico hacen realidad los mayores beneficios al consumir servicios ya
que pueden aprovechar los mecanismos de almacenamiento de
datos locales y el poder informtico que no estn disponibles a
travs de mecanismos de entrega basados en la Web. Las
aplicaciones de Web poseen el beneficio de ser alojadas y manejadas
de forma central pero, al depender de la conexin no pueden realizar
completamente la experiencia del usuario conectada. Una aplicacin
de cliente rico, adems de brindar la experiencia de usuario ms
completa, se beneficia con ms facilidad de los servicios que tal vez
estn disponibles slo de forma local. Es ms prctico consumir y
evaluar los datos de rendimiento del vehculo de forma local en el
vehculo que transferir datos a la nube para un procesamiento
adicional. Tambin se evita cualquier tipo de problema de privacidad
y seguridad cuando no se transmiten datos desde el automvil hacia
servicios remotos.
Por ltimo, una aplicacin de cliente rico puede tratar la identidad
y sesin de un modo ms fcil que una aplicacin basada en la Web.
Es una tarea trivial almacenar tarjetas de informacin de forma local
en un dispositivo y utilizar esas tarjetas para establecer identidad
con un servicio u otra aplicacin.
Patrones de entrega de servicios
Podemos esperar que la conexin a Internet est ampliamente
disponible para nuestra solucin, pero no podemos presuponer que
la conectividad sea ubicua. Cada patrn de entrega de servicios
posee diferentes calidades en lo que se refiere a latencia, flexibilidad
y funcionalidad (Tabla 3). Un cliente rico nos permite adoptar un
conjunto de patrones de diseo con los cuales podemos no slo
manejar esas ocasiones en las que estamos desconectados de la red,
sino tambin utilizar capacidades adicionales del cliente para hacer
posible la experiencia de usuario.
Muchas aplicaciones ricas que se construyen en estos das son
slo shells que proporcionan entrada y salida a un conjunto de
servicios que reside detrs de la interfaz de usuario. En este patrn,
el cliente depende mucho de la conectividad para brindar cualquier
tipo de interaccin til para el usuario final. Este cliente puede tener
un simple almacenamiento en cach para tratar la latencia de red o
condiciones en las que la red simplemente no est disponible, pero
esto no extiende su utilidad ms all de lo que est disponible a
travs de los servicios que consume.
Se puede extender este patrn para crear un segundo patrn ms
til en el que el cliente permanece como consumidor dependiente del
servicio, pero la infraestructura informtica se extiende hacia el
cliente. En otras palabras, aprovechamos la capacidad de la
aplicacin de realizar tareas de procesamiento en el vehculo, por
Tabla 3: Comparacin de arquitecturas de cliente
Patrn
Consumidor de
servicio liviano
Cliente
enriquecido
Cliente
inteligente
Latencia
Flexibilidad
Funcionalidad
Alta
Alta
Media
Media
Media
Media
Baja
Baja
Alta
Figura 6: Permite diferentes accesos para una mejor utilizacin de

servicios y una experiencia de usuario ms diferenciada.
consiguiente, el servicios se libera de cierta carga del procesamiento.

Un resultado tpico en este caso es una aplicacin ms receptiva,
aunque an, rinde menos de lo esperado.
A menos que se descargue toda la funcionalidad en el dispositivo del
cliente, se puede implementar un patrn en el que los servicios se
conviertan en simples consumidores y proveedores de datos. La lgica
para el modo en el que se utilizan los datos est incrustada en el
cliente y el cliente pasa a ser el punto central de la experiencia de
usuario. Este patrn permite tratar con la latencia que causan las
conexiones de red lentas o inexistentes, as como tambin presentar al
usuario una experiencia que se asemeje a la de la PC de su hogar. Un
problema relacionado con este patrn es el de capacidad de
actualizacin. Debido a que la aplicacin se implementa en el
dispositivo del cliente, es mucho ms difcil aadir funcionalidad o
actualizar la funcionalidad existente. Los servicios como el modelo de
implementacin de un slo clic de .NET Framework y la adopcin de
patrones de aplicacin de IU compuesta ayudan a superar este desafo.
Se pueden actualizar e incorporar nuevos servicios fcilmente, como es
el caso de cualquier servicio de Web.
Los vendedores de software y proveedores de servicios pueden
ofrecer versiones mltiples de sus productos, por ejemplo, una versin
de vehculo independiente para dispositivos que se ofrecen a travs de
canales minoristas regulares y una versin de vehculo especfico que
se ofrece a travs del fabricante del vehculo que brinda funcionalidad
adicional (Figura 6). Un modelo mejorado iluminara la experiencia en
el dispositivo y en el automvil cuando un cliente compra ambos
productos. Esta aplicacin para dispositivos mviles podra tambin
ofrecer caractersticas adicionales valiosas, como por ejemplo la
exhibicin de la ubicacin del automvil en un determinado momento,
inicio remoto y sincronizacin automtica de datos desde el dispositivo
cuando se coloca dentro del automvil. Ambas, la aplicacin del
dispositivo y la aplicacin del vehculo pueden acceder a los servicios
basados en la nube del proveedor de servicios, lo que permite
incrementar su utilizacin debido a la mayor cantidad de destinatarios.
Con la arquitectura de S+S, las aplicaciones cliente no estn sujetas
al vehculo. Los servicios se pueden ofrecer a travs de una gran
cantidad de dispositivos de consumo como telfonos inteligentes y PCs
mviles con experiencias de usuario hechas a medida para esas
plataformas. Debido a que los datos que se almacenan en la nube
estn disponibles para todos y cada uno de los dispositivos, se puede
realizar la transicin entre dispositivos casi sin problemas. El principio
importante que se debe mantener es que la interaccin con los
dispositivos debe ser una experiencia natural para el usuario. La
creciente variedad de dispositivos cada vez ms poderosos presenta
muchas opciones para introducir un nivel consistente de interaccin
entre el cliente y la computadora. La interfaz de usuario puede cambiar
para adaptarse a factores de forma, pero el nivel del servicio
continuar siendo el mismo.
21

Figura 7: Los automviles y los conductores necesitan sus propias
identidades digitales diferentes para acceder a los servicios.
la transmisin de identidad personal o combinaciones de contrasea/

nombre de usuario dbiles.
Debido a la privacidad, se recomienda encarecidamente a los
proveedores de servicios que no soliciten ninguna informacin
confidencial. Para todas las excepciones, el proveedor de la aplicacin
debe solicitar autorizacin al usuario para transmitir informacin al
servicio. De forma predeterminada, cada aplicacin debe seguir las
instrucciones de Microsoft para asegurar la informtica para no
transmitir ninguna informacin confidencial sin autorizacin explcita
del usuario.
Seguridad, identidad y el cliente

La identidad es un desafo en cualquier sistema como tambin lo son
la autenticacin, la autorizacin y la privacidad. ste es
especficamente el caso con las aplicaciones mviles. Cuanto ms
aplicaciones existen entre la aplicacin principal y el dispositivo, ms
difcil es tratar los asuntos de seguridad. Un cliente ms rico permite
mantener tokens de seguridad en el dispositivo y de este modo crea
una aplicacin discutiblemente ms segura.
Comunicacin segura
La privacidad es una de las incumbencias ms importantes para
cualquier persona que intercambia datos con servicios en la nube. En
el pasado, el centro de atencin estaba sobre HTTPS y SSL para la
transmisin de informacin codificada. El problema con SSL es que es
un protocolo punto-a-punto y no permite que los datos se
intercambien de forma segura entre los mltiples puntos finales. Las
aplicaciones compuestas (que comprenden servicios mltiples casi
por definicin) requieren para la seguridad un enfoque integral. Una
mejor solucin sera ocultar los datos en el dispositivo y permitir que
sean transportados sobre una conexin codificada o clara. Este es el
enfoque que tomaron los autores del protocolo WS-Security. El
dispositivo del cliente procesa una clave pblica que se utiliza para
codificar los datos antes de que sean liberados para su traslado. Slo
el servicio destino puede decodificar el mensaje. Los datos en el
mensaje previstos para diversos destinatarios se pueden codificar con
diferentes claves pblicas, lo que permite asegurar que los datos sean
slo ledos por el destinatario previsto. Las plataformas de desarrollo
del lado del cliente, como las diversas versiones de .NET Framework
implementan WS-Security como parte de WCF.
Las firmas digitales brindan una medida de confianza adicional. El
cliente puede utilizar un identificador nico, como una clave privada,
desde un certificado X.509 para firmar el mensaje, y de este modo
permite asegurar que los datos sean efectivamente enviados por la
parte cuya identidad se aduce en el mensaje; la firma digital tambin
brindara la seguridad de que los datos no fueron manipulados en
trnsito. Una firma digital es esencialmente un hash unidireccional de
los datos de origen. Si el destinatario no puede reproducir el hash, se
entiende que la firma es invalida: Ya sea porque el par de la clave no
concuerda, lo que invalida la identidad aducida o porque los datos se
han manipulado en trnsito.
El enfoque S+S permite el uso de WS-Security, pero incluso ofrece
una opcin ms segura para mejorar la privacidad: No trasmite
ninguna informacin segura. Transferir operaciones informticas hacia
el auto o el dispositivo que incluyen datos que se reconocen de forma
personal elimina la necesidad de transmitir la informacin sobre
canales que no son seguros. Tomemos como ejemplo la autenticacin
de CardSpace. Una identidad CardSpace vinculada al automvil evita
22
Autenticacin y autorizacin
Las tokens de identidad se pueden utilizar para autenticar y autorizar
usuarios hacia los servicios que desean acceder. Una tarjeta de
informacin como CardSpace le permitira al usuario presentar un
reclamo de identidad hacia un servicio. La carga de verificar la
identidad podra ser responsabilidad del servicio o podra utilizarse una
parte dependiente para validar la identidad. La autorizacin an sera
responsabilidad del servicio que se invoca.
La autenticacin es muy importante en nuestro escenario mvil por
varios motivos: Es necesario restringir el acceso a la aplicacin para los
clientes que pagan por el servicio, pero tambin es necesario asegurar
que los datos privados de cada usuario sean protegidos a travs del
acceso autorizado. En nuestro escenario existe una incumbencia
adicional: El acceso remoto al automvil. Existen incumbencias de
privacidad sobre el acceso al historial de viaje y ubicacin del
automvil, pero existen tambin incumbencias de seguridad. Por
ejemplo, el arranque o detencin del automvil es una caracterstica
que debe controlarse cuidadosamente. Nadie deseara que un hacker
malintencionado apague el motor del automvil mientras uno maneja
en una autopista.
EL ENFOQUE S+S PERMITE EL USO DE WSSECURITY, PERO INCLUSO OFRECE UNA OPCIN
MS SEGURA PARA MEJORAR LA PRIVACIDAD:
NO TRASMITE NINGUNA INFORMACIN SEGURA.
TRANSFERIR OPERACIONES INFORMTICAS
HACIA EL AUTO O EL DISPOSITIVO QUE
INCLUYEN DATOS QUE SE RECONOCEN DE FORMA
PERSONAL ELIMINA LA NECESIDAD DE
TRANSMITIR LA INFORMACIN SOBRE CANALES
QUE NO SON SEGUROS.
En Internet, la identidad de usuario habitualmente se establece
mediante el ingreso de una combinacin de nombre de usuario/
contrasea pero sta no es la experiencia que esperamos al ingresar al
automvil. La llave es la forma tradicional de acceder al automvil y a
sus servicios. Se puede utilizar un modelo de interaccin similar para
escenarios de servicios conectados con claves inteligentes o soluciones
basadas en CardSpace.
Sin embargo, existen algunas incumbencias de arquitectura
interesantes en torno a la identidad en el automvil. Por un lado, el
automvil en s mismo es una aplicacin multicliente ya que puede
tener mltiples conductores potencialmente con diferentes funciones:
el propietario, la hija adolescente del propietario, un mecnico que
repara el automvil, son algunos ejemplos. Muchos automviles hoy en
da ofrecen configuraciones de preferencias en las posiciones del
volante y el asiento para los diferentes conductores basados en la clave
que llevan. Esta experiencia se puede extender hacia los dispositivos

Figura 8: La plataforma de servicios en Internet permite una
experiencia de consumidor conectada en el automvil, el dispositivo y
la PC.
informticos del vehculo, lo que permite que las aplicaciones y los

datos estn disponibles de acuerdo a la identidad de conductor. El
acceso a todo el sistema se puede limitar para los invitados en el
automvil.
El concepto de identidad existe incluso para el vehculo mismo
(Figura 7). Podra asignarse un identificador digital a los automviles
individuales, y de este modo permitir el acceso a los servicios del
fabricante que brinda servicios especficos para vehculo. Por otro
lado, los conductores necesitan una identidad porttil. La mayora de
los usuario de computadoras en la actualidad poseen al menos una
identidad digital asociada con ellos. Extender esa identidad para que
se pueda utilizar en un vehculo no es algo trivial, pero es algo
absolutamente posible.
Arquitectura de datos multicliente
Otro factor para considerar es el problema de la privacidad y el
almacenamiento de datos. Para lograr que este tipo de experiencia
informtica sea til es necesario almacenar en la nube una buena
cantidad de informacin personal. Esto crea un desafo para el
arquitecto de datos quien debe asegurarse que los datos se
almacenen de forma eficaz y al mismo tiempo debe asegurarse de no
comprometer la seguridad y privacidad de un usuario que utiliza el
servicio.
Posiblemente, la mejor solucin para un almacn de datos con una
gran cantidad de clientes sea la base de datos compartida, mtodo de
esquema compartido. En este caso, los datos de cada cliente se
almacenan en las mismas tablas con datos asociados a cada cliente
mediante metadatos. Este patrn concede la garanta de privacidad y
seguridad sobre cualquier aplicacin que acceda a los datos y puede
establecer costos adicionales de desarrollo de software, pero el ahorro
de costos que se percibe en el mantenimiento de los datos a largo
plazo, vale ms que ese costo.
Conclusin
Las experiencias conectadas del usuario como la que se describieron
en este artculo presentan una gran oportunidad para aadir valor a
los productos existentes. La generacin actual as como tambin la
prxima generacin de consumidores posee un amplio conocimiento
sobre la tecnologa y dependern de asistentes digitales en todas
partes, no slo en los escritorios de sus oficinas. La ubicuidad de los
dispositivos informticos y la amplia disponibilidad de conectividad a
la red presentan una oportunidad para que los fabricantes y nuevos
proveedores de servicios se conecten con sus clientes de formas
nuevas y significativas (Figura 8).
El automvil en particular es una parte importante en la vida de
muchas personas. Uno lleva los a los nios a la escuela, visita
clientes, o se va de vacaciones con el automvil. Uno tal vez pasa
muchas horas conduciendo todas las semanas y se encuentra en

situaciones en las que alguna ayuda extra podra ser importantsima.
La plataforma de Microsoft es muy apropiada para construir
soluciones de S+S en el cliente o en el servidor. Tecnologas como WCF
y el .NET Framework son muy apropiadas para construir servicios en la
nube ya que admiten protocolos de intercambio de mensajes, como
JSON, POX/REST, SOAP y WS-*, y garantizan la interoperabilidad con
todo tipo de consumidores de servicios. Con frecuencia, los servicios no
se construyen partiendo de cero sino ms bien agregando servicios
existentes. Las tecnologas como el servidor BizTalk o los servicios de
BizTalk basados en la nube son ideales para servicios de bloques de
construccin dentro de servicios de valor agregado. La plataforma
tambin ofrece servicios de bloques de construccin de Windows Live,
como contratos, alertas o fotos, que se pueden incluir en los servicios
de valor agregado.
El Software+Servicio brinda un excelente patrn para la entrega de
servicios en una gran cantidad de plataformas. Los mecanismos de
entrega de servicios flexibles permiten aadir rpidamente nuevas
caractersticas con poca interrupcin a los servicios existentes. Los
avances en las tecnologas de presentacin y los factores de forma de
los dispositivos hacen posible presentar a los usuarios software de la
forma ms apropiada de acuerdo al contexto.
Ya estamos viendo el surgimiento de la combinacin de Software+
Servicios en varias reas. Quienes primero lo adoptaron brindan el
valor de estas soluciones y establecen un nuevo desafo para que otros
lo superen. Las herramientas y las plataformas ya existen. Slo
depende de los proveedores de aplicaciones construir aplicaciones que
lleguen a los usuarios de la mejor forma posible.
Sobre los autores

Darryl Hogan es arquitecto del grupo Developer and Platform
Evangelism de Microsoft. Darryl posee amplia experiencia en el diseo
e implementacin de numerosas aplicaciones empresariales en la
industria TI durante casi 15 aos. En su funcin actual, Darryl brinda
orientacin y educacin a arquitectos que implementan soluciones
empresariales y arquitecturas empresariales sobre tecnlogos de
Microsoft.
Christoph Schittko es arquitecto de Microsoft con sede en Texas
donde trabaja con clientes para construir soluciones poderosas que
combinan Software + Servicios para experiencias de usuario
vanguardistas y mejorar las soluciones de arquitectura orientada a
servicios (SOA). Antes de unirse a Microsoft, Christoph ayud a
compaas en la adopcin de orientacin al servicio y en la entrega de
soluciones de software + Servicios (SaaS). Christoph posee ms de 14
aos de experiencia en el desarrollo y arquitectura de soluciones de
software en una gran variedad de industrias. Escribe y diserta en varias
conferencias en XML y servicios de Web. Christoph obtuvo un ttulo
superior en Ingeniera Elctrica en Friedrich-Alexander University
Erlangen-Nrnberg.
Jon Box es arquitecto evangelista en Microsoft. Trabaja con clientes
para utilizar tecnologas de Microsoft y construir soluciones que tengan
gran impacto. Jon ha programado profesionalmente desde 1985. Ha
trabajado en una variedad de entornos y lenguajes que incluyen
COBOL, Assembler, Clipper, C, C++ (Borland, ATL, MFC, Win32,
COM/DCOM), VB5/VB6 y .NET. Para obtener ms informacin sobre sus
ideas, consulte su blog en http://blogs.msdn.com/jonbox.
23
Perfil del Architecture

Journal: Faisal Waris
En esta edicin, nos pusimos al da con Faisal Waris,
consultor de arquitectura en Ford. The Architecture Journal le
pregunt sobre su funcin, algunos de los desafos que
enfrente y sus visiones sobre la arquitectura.
AJ: Faisal Podra contarnos un poco sobre usted?
FW: Soy consultor en Ford Motor Company, donde trabajo para
Synova Corporation. Fundamentalmente, mi funcin principal en Ford
es arquitecto de SOA y he estado aqu por cuatro o cinco aos.
Tambin soy co-presidente de un grupo de trabajo AIAG que se ocupa
de mensajera negocio-a-negocio (B2B). AIAG significa Automotive
Industry Action Group (Grupo de accin de la industria automotriz),
un organismo de normalizacin para la cadena de suministro
automotriz. Cuenta con una membresa bastante amplia que est
compuesta de varios OEMs y proveedores.
AJ: Cuatro o cinco aos en Ford como arquitecto de SOA
parece una funcin fascinante. Podra ampliarnos un poco
ms sobre su trabajo?
FW: El equipo en el que trabajo es parte del Grupo de Arquitectura
Empresarial, que asume varias funciones. Primero, en algunos
aspectos somos similares a una organizacin de investigacin,
estudiamos tecnologas emergentes, realizamos pruebas de conceptos
y experimentamos con software y dispositivos para descubrir si algo
podra aadir valor a Ford. A continuacin, diseamos esa tecnologa
para los equipos de aplicacin predominantes. La otra funcin del
grupo es establecer normas, que puede incluir la definicin de normas
y mejores prcticas en lo que respecta a la Arquitectura Orientada a
Servicios (SOA) y otros temas de arquitectura. La gobernabilidad de
SOA es un rea principal sobre la cual estamos trabajando
actualmente. Esto implica la creacin de procesos, estructuras y el
uso de pautas para los productos y servicios de toda la empresa que
se incorporan a Ford. Tambin ayudamos a los equipos de
aplicaciones a implementar servicios de Web SOA y a resolver
problemas cuando las cosas no salen bien.
AJ: Muchos de nuestros lectores tal vez estn implementando
SOA Qu recomendaciones compartira con ellos?
FW: Uno de los debates que tenemos aqu, y yo creo que es algo que
probablemente est sucediendo en muchos otros lugares, es la
pregunta: Qu es un servicio? De qu se compone un servicio? Si
tengo un trabajo en FTP Es esto un servicio? La palabra servicio
slo describe un servicio de Web o tambin abarca un servicio en
AJAX? Creo que muchas compaas, incluidos nosotros, tenemos
dificultades con la definicin. Hemos decidido adoptar un modo muy
pragmtico de enfrentarla. Para resolver esto usamos la definicin de
OASIS. Pueden ingresar a OASIS y obtenerla directamente desde su
sitio de Web. Decidimos utilizarla como nuestra definicin porque
muchas personas trabajaron en ella, por lo tanto, es una especie de
visin de consenso sobre el modo de definir SOA. Es incluso una
definicin muy genrica, pero lo que permite hacer es adecuarla para
un uso especfico. Si uno piensa sobre la definicin, casi todo podra
24
ser un servicio, pero si uno desea tener una arquitectura que

conecte todos esos servicios de un modo uniforme, lo que difiere de
la definicin de OASIS, entonces uno debe comenzar a pensar en lo
que realmente deseara que fuera un servicio. Descubrimos que si
uno desea uniformidad en los servicios, entonces, el primer paso es
establecer un cierto conjunto de normas y protocolos.
AJ: Mencion un nfasis sobre la gobernabilidad Considera
que varias organizaciones en la actualidad tienen dificultades
con la gobernabilidad?
FW: Creo que depende de la madurez de la organizacin, o la
madurez de SOA en la organizacin. Si uno recin se est iniciando,
por supuesto, arduas tareas de gobernabilidad no es lo que
realmente se necesita. Lo que se necesita en ese momento es
ayudar y enriquecer la SOA emergente en la organizacin. Esto
puede incluir el evangelismo de SOA, charlas con los equipos de
aplicaciones y la explicacin de conceptos y del modo en el que las
cosas se deben hacer. Despus de un determinado tiempo, cuando
todos estn conformes y se estn construyendo servicios, entonces
uno puede detenerse a pensar y prestar un poco ms de atencin a
la gobernabilidad. Como organizacin, estamos ahora en esta
transicin. Hemos realizado la evangelizacin, y SOA ha sido
aceptada. Estamos ahora en la etapa en la que necesitamos
empezar a pensar el modo de administrar todo esto y debemos
asegurarnos que se estn construyendo los servicios correctos, lo
que permite evitar la duplicacin; dado que contamos con diferentes
equipos de aplicaciones con diferentes puntos de vista, entonces
cmo podemos desarrollar los servicios apropiados para tener los
consumidores y proveedores adecuados y el grupo de interfaces
necesario.
AJ: Tambin mencion que co-preside un grupo de trabajo de
AIAG. Podra brindarle a los lectores una breve introduccin
sobre AIAG, en especial, en relacin con la misin del grupo?
FW: AIAG es ms que simplemente un grupo de accin; es un
vertical para la cadena de suministro y un organismo de
normalizacin. Rene a los proveedores y OEMs (Fabricantes de
equipos originales) y hace que trabajen juntos sobre problemas
comunes. Existen normas relacionadas con la ingeniera y normas de
procesos, pero cada vez ms se dedican a normas relacionadas con
el comercio electrnico, stas son normas relacionadas con el
intercambio de informacin entre proveedores y OEMs. Yo soy parte
del grupo que trabaja con ese conjunto de normas y nuestra meta es
hacer posible la integracin transparente entre los participantes de la
cadena de suministro automotriz mediante la definicin de procesos
comerciales estndares. Un proceso estndar podra ser algo como
un proceso de gestin de inventario, procesos de garanta o calidad,
es decir Kanban, MinMax. A continuacin, tomamos estos procesos y
realizamos pruebas de conceptos mediante el uso de servicios de
Web y tecnologas relacionadas (como ebMS). Demostramos que
muchas implementaciones de un proceso comercial (con interfaces
que se definen a travs de un conjunto de WSDLs) pueden
interactuar de forma segura y confiable. Nuestra meta es fomentar
esto en la industria.
Perfil del Architecture Journal: Faisal Waris

AJ: La edicin actual de The Journal trata sobre los
dispositivos y las aplicaciones mviles. Algunos de los lectores
tal vez se han enterado del nuevo producto de Frod Sync
Podra contarnos un poco sobre esto?
FW: Sync es una asociacin entre Microsoft y Ford y es una de las
primeras aplicaciones de Microsoft Automotive PC que se utiliza para
la produccin. Sync es muy interesante. En su contexto actual, Sync
brinda servicios relacionados con el entretenimiento, reconocimiento
de voz, funcionamiento del telfono y dispositivos multimedia. Una
forma de ver este producto es como una plataforma informtica de
propsito general en automviles. Con este paradigma, el cielo es el
lmite, existen infinidad de posibilidades en lo que respecta a lo que
se puede hacer con l. Por supuesto, existen desafos relacionados
con lo que se puede poner en un automvil desde la perspectiva del
usuario debido a las diversas consideraciones. Pero est comenzando
un nuevo mundo y estamos muy emocionados de ser una parte de
esto.
AJ: Cmo piensa que evolucionar la funcin del software en
los automviles durante los prximos aos?
FW: Ford claramente est pensando en muchas reas diferentes,
algunas de las cuales no puedo mencionar en esta entrevistas por
motivos de confidencialidad, pero una plataforma informtica de
propsito general en el automvil plantea muchos sueos y
posibilidades. Existe un potencial para la provisin de varios servicios
dentro de un automvil que pueden funcionar sobre el reconocimiento
de voz, en especial, uno que puede desempearse bien en el entorno
automotriz.
AJ: Descubrimos que varios lectores de The Architecture
Journal aspiran a ser arquitectos, tal vez desarrolladores
senior que buscan la prxima etapa de sus carreras y piensan
sobre lo que necesitan para llegar a ser arquitectos. Como
alguien que ha desempeado esta funcin por algn tiempo
Qu consejo le dara a alguien que desea ser arquitecto en la
actualidad?
FW: Considero que existe un proceso gradual en el que se pasa de
desarrollador a lder de desarrollo y despus a arquitecto. Tambin
existen diversos tipos de arquitectos. En Ford contamos con
arquitectos de infraestructura, arquitectos de soluciones e incluso
arquitectos especficos como arquitectos de SOA. Si uno aspira a ser
arquitecto, creo que estar al da con la informacin es clave ya que
poder comprender el modo de tomar un grupo de tecnologas e
incorporarlas dentro de una solucin requiere un conocimiento
bastante amplio y un conocimiento bastante actualizado de lo que
ocurre en el mundo. Yo debo leer muchsimas cosas simplemente
para mantenerme al da con las cosas que suceden. Tambin soy ms
un arquitecto participativo, por lo tanto, si bien desempeo una
funcin de arquitectura, me gusta arremangarme la camisa y
modificar un poco de cdigo. He descubierto que esto es realmente
beneficioso. Muchos arquitectos evitan hacer algn tipo de trabajo
participativo, lo que puede ser un error porque uno realmente no
puede disear a menos que comprenda toda la situacin y a veces,
uno debe comprender las cosas en un gran nivel de profundidad para
poder tomar el tipo de decisiones correctas. Mi consejo sera que
practiquen mucho con nuevas tecnologas y que experimenten. No es
necesario escribir aplicaciones de produccin, pero lo que se puede
hacer es experimentar para tener una idea de lo que algo puede
hacer, sus lmites y sus capacidades, y todo esto en conjunto brinda
una perspectiva mucho mejor de lo que funcionar y lo que no.
AJ: Una de las cosas que siempre nos gusta preguntarles a las
personas en las entrevistas es De qu se arrepiente ms en
su carrera y qu aprendi de eso?
FW: sta es difcil de responder! En realidad no puedo recordar algo
de lo que realmente me arrepienta. He tenido varias oportunidades
de participar completamente en la administracin, pero he tratado de
evitarlo. Siempre tuve un pie en el rea tcnica. Creo que eso me ha
ayudado a estar donde estoy en la actualidad. Al estar en esta
Faisal Waris trabaja para Synova Corp.

y es arquitecto consultor de SOA en
Ford Motor Company. Recientemente
ha participado en el programa de Sync
(www.syncmyride.com). Sync es el
resultado de una asociacin entre
Microsoft y Ford y es una de las
primeras aplicaciones de produccin de
Automotive PC de Microsoft. Faisal
Faisal Waris
tambin es co-presidente de un grupo
Synova Corp.
de trabajo en el grupo de accin de la
industria automotriz (AIAG, www.aiag.com) donde trabaja sobre
normas de comercio electrnico en automviles.
posicin, considero que podra experimentar una limitacin y la pregunta
puede ser Cmo avanzo en esta posicin? Debera darse un cambio
hacia la administracin o permanecer en una funcin de arquitecto de
consultora? o Cmo se avanza? Esta es una de las cosas que necesito
averiguar.
AJ: Con relacin a su carrera Qu espera lograr en los prximos
aos y a largo plazo?
FW: Uno de mis objetivos personales es establecer una nueva forma de
tratar la mensajera B2B. Si analizamos lo que tenemos en la actualidad
en lo que se refiere a mensajera, es en su mayora Intercambio
Electrnico de Datos (EDI). Se est implementando algo de XML, pero si
uno lo analiza, es an en la mayora de los casos EDI sobre FTP. Mi
objetivo personal es hacer posibles servicios de Web B2B y creo que
contamos con todos los componentes. Tenemos especificaciones WS-*
que funcionan bien en el espacio de B2B. Por ejemplo, contamos con WSAddressing para la mensajera asncrona, WS-ReliableMessaging para la
entrega eficaz de mensajes, WS-Atomic-Transaction para las
transacciones, WS-Security y WS-SecureConversation para la seguridad,
etc. Varios de los conjuntos de herramientas en la actualidad
implementan estas normas, por lo tanto, una de las cosas sobre las
cuales estoy trabajando en Ford y en AIAG es en establecer stas normas
como las nuevas normas de la mensajera B2B. Por supuesto, es muy
difcil debido a la gran base instalada de tecnologas existentes, pero
lentamente, comenzamos a ver personas que reconocen el valor del
intercambio de mensajes con XML porque uno puede hacer mucho ms
con XML. A diferencia del EDI, varios aspectos de la mensajera de XML
pueden manejarse simplemente mediante el uso de metadatos (como
XML Schema, WSDL, WS-Policy, etc.). Adems, se pueden crear
integraciones robustas, mediante la mensajera confiable, que es difcil
con algo como EDI. Esta es mi misin personal, es muy gratificante y
apasionante.
Otra rea de tecnologa que personalmente me interesa son las
tecnologas de Web semntica. En la actualidad, tal vez se est volviendo
un poco antiguo, creo que ha superado la curva del sensacionalismo e
incluso tal vez est en la cada hacia la desilusin, pero cuando trabajo
con informacin, veo el modo en el que se podran manejar mejor y
siempre vuelvo a las capacidades prometidas en la visin de Web
semntica. Espero que estas necesidades sean reconocidas por otros y tal
vez exista un resurgimiento.
En este momento estoy muy feliz con lo que hago y muy pero muy
ocupado, por lo tanto no he tenido tiempo de pensar en el largo plazo.
Definitivamente me gusta la funcin de arquitecto y no s si quiero dejar
de ejercerla en un futuro cercano.
AJ: Faisal Muchas gracias por compartir algunos de sus
observaciones y pensamientos!
Si desea proponer a alguien que sera un buen candidato para el perfil de
la prxima edicin de The Journal, por favor pngase en contacto con los
editores en editors@architecturejournal.net
25
Arquitectura de datos
mviles
Por Rodney Guzman
Sntesis
Las aplicaciones que estn conectadas de forma ocasional
tienen fama de ser difciles de implementar. Los desafos se
dan por niveles y el centro del problema es el modo en el
que se administran los datos. Cada cliente conectado
ocasionalmente consume y produce datos en intervalos al
azar. Las islas de datos se producen cuando no hay conexin
y se debe reconciliar ms tarde cuando se restaura la
conectividad. Las tecnologas existen para mover datos
desde y hacia los clientes, sin embargo, slo las tareas de
reconciliacin ms simples se administran sin la intervencin
de cdigo personalizado. Por ejemplo, La replicacin de SQL
es una tecnologa fantstica para mover datos nuevos de un
sistema a otro. Pero cuando ms de un cliente actualiza un
registro, debera ganar siempre el ltimo en entrar?
Tambin, Qu sucede cuando se crean nuevas entidades de
datos en mltiples clientes, pero cada una representa la
misma instancia de entidad nica? Desafortunadamente, los
modelos de datos habitualmente son demasiado complejos
para que sean administrados por procesos de resolucin de
conflictos genricos.
Este artculo analizar el modo de construir un modelo de
datos que admite una aplicacin conectada ocasionalmente.
El modelo de datos admite la introduccin de un proceso de
resolucin de conflictos complejo construido en .NET. Se
presenta una aplicacin modelo de puntos de servicio con
requisitos exigentes, que incluyen: Puntos de entrada de
cliente inteligente y de Web; clientes inteligentes que se
conectan ocasionalmente; entidades de datos que incluyen
mltiples tablas y un proceso de resolucin de conflictos
complejo que incluye soporte para los nuevos registros que
se pueden crear en la aplicacin de Web y/o instancias de
aplicacin de cliente inteligente.
Escenario
Para este artculo se presenta una aplicacin de gestin de eventos
modelo. Esta aplicacin es un sitio de Web alojado con un modelo de
datos eficaz. La empresa requiere que esta aplicacin se pueda
acceder en reas desconectadas, remotas, en las que se llevan a cabo
los eventos. En los eventos, se pueden comprar productos de la
compaa y se puede actualizar informacin de quienes asisten
simplemente del mismo modo que se hace en un sitio de Web. Cada
evento puede durar varios das con miles de asistentes. Durante el
evento, no existe un regularidad con la que se puede asumir que
26
se tiene conectividad a la red. Poco despus que termina el evento,

los datos de cada cliente deben reconciliarse. El diagrama
simplificado de la base de datos que se muestra en la Figura 1 se
toma de referencia como un subconjunto modelo de esta aplicacin.
La empresa ha requerido la reutilizacin de los componentes
existentes para minimizar el costo de construccin de una aplicacin
de cliente inteligente. La empresa no quiere volver a construir sus
objetos de negocio que ya han sido abstrados correctamente desde
su aplicacin ASP.NET. Quieren que los mismos objetos de negocio
se implementen con la aplicacin de cliente inteligente Windows
Presentation Foundation (WPF). El SQL Express se utilizar en el
escritorio y el esquema de datos se reutilizar desde la aplicacin de
Web.
Cuando uno est conectado
Uno nunca se puede basar en el momento en el que estarn
conectadas las aplicaciones que se conectan ocasionalmente, lo que
impone una tremenda carga en la aplicacin. Una aplicacin debe
estar conectada en determinados momentos para desempear
funciones de base. Para nuestro escenario de ejemplo, para
optimizar la experiencia del evento de quienes asisten, se debe
poder acceder a la informacin de preinscripcin en el cliente
desconectado durante el evento, por lo tanto, el dispositivo se
sincroniza con el almacn de datos central antes del evento. Sin
importar el modo en el que se intercambia la informacin, el
dispositivo debe conectarse antes del inicio del evento para obtener
esta informacin.
Los requisitos iniciales para la aplicacin incluyeron un modelo
que admita una aplicacin que nunca requera al usuario para
conectarse y desempear una funcin. Paradjicamente, el usuario
deba conectarse en algn punto del ciclo de vida del uso de la
aplicacin para que los datos se pudieran sincronizar hacia y desde
el servidor. La falta de control sobre el momento en el que la
aplicacin podra estar conectada planteo complejidades que no se
podan ignorar. En el caso de la aplicacin, se modificaron los
requisitos para forzar a la aplicacin a que est conectada en
momentos claves.
Complejidad de nunca saber cundo se est conectado
La replicacin de SQL admite muy bien el concepto del intercambio
de datos con clientes conectados ocasionalmente. Sin embargo, si se
administra un proceso de mltiples pasos en el que cada paso se
basa en algn tipo de conectividad, saber el punto en el que se
encuentra el proceso puede ser un desafo. En la aplicacin de
gestin de eventos, para basarse exclusivamente de la replicacin de
SQL, el flujo del proceso debera asemejarse a lo siguiente:
1.
La lista de eventos disponibles se replicara hacia cada

dispositivo cliente. Si se agrega un evento nuevo, o se modifica
uno existente, debera sincronizarse con cada dispositivo.

3.
Figura 1: Versin extremadamente reducida de las tablas de SQL.
Las normas de replicacin de SQL filtrada asocian los

eventos con los nombres de hosts, y especifican los
eventos que se replicarn hacia dispositivos de cliente
determinados.
A travs de los servicios de Web se puede obtener

muchsima informacin adicional, desde la cantidad de
registros que se sincronizarn hasta actualizaciones de
progreso con respecto a si ha ocurrido una replicacin o est
completa.
2. Autorizacin para las personas que pueden ver los eventos que se
replicarn a cada dispositivo de cliente. Si la autorizacin cambia,
debera replicarse.
3. En el dispositivo local, el usuario selecciona el evento a sincronizar
de modo que coloca un registro en la tabla EventDownload en la
base de datos local que incluye el nombre del host del equipo del
cliente y el evento a replicar.
4. La tabla EventDownload se vuelve a replicar hacia el servidor.
5. La replicacin de SQL filtrada transfiere el evento solicitado hacia el
dispositivo del usuario.
Este flujo de proceso parece lo suficientemente simple, pero requiere
conectividad durante todo el proceso. Imaginemos una conversacin
con un usuario sin conocimientos tcnicos sobre el motivo por el cual
no pudo ver el evento en su dispositivo porque la autorizacin que le
conceda acceso cambi despus de que l haba sincronizado su
equipo. Basarse en un modelo en el que uno nunca puede controlar la
conectividad puede ser complicado de depurar y mantener.
Depender de momentos claves de conexin
A la larga, la conectividad es necesaria en algn punto. A diferencia
del modelo de replicacin SQL puro, se puede tomar un enfoque ms
directo para simplificar todo el procesamiento. Exigir la conectividad
en puntos clave evita varios de los recorridos de ida y vuelta que se
describen en la seccin anterior. Por ejemplo, en vez de sincronizar la
lista de eventos con la base de datos local, se puede invocar un
servicio de Web para recuperar una lista de eventos autorizados con
los cuales pueda sincronizar el usuario, lo que cambiara el flujo de la
siguiente manera:
1. El usuario inicia la aplicacin y recupera una lista de eventos a
travs de una llamada a un servicio Web. Slo se muestran al
usuario los eventos autorizados.
2. El usuario selecciona un evento y realiza nuevamente una llamada
al servicio Web. En el servidor se establece un registro en la tabla
EventDownloas con el nombre de host del dispositivo del usuario.
Resolucin de conflictos
La replicacin de SQL y ADO.NET no brindan la solucin
milagrosa para la resolucin de conflictos. La mayora de
nuestras aplicaciones simplemente son demasiado
complicadas para ser administradas por soluciones listas para
usar. No podemos siempre basarnos en el ltimo en entrar
gana, por lo general, es necesario esperar a que los datos
se acumulen desde mltiples fuentes antes de tomar una
decisin sobre cul es el mejor registro.
Este panorama parece abismal, pero existen tecnologas
que reducen esta complejidad. En la aplicacin de gestin de
eventos, nos basamos en los puntos fuertes de la replicacin
de SQL como un principio bsico para la solucin. Un punto
fuerte observado de la replicacin de SQL es que es
fantstico para administrar inserciones de SQL. Sin embargo,
para las actualizaciones, haba demasiados escenarios sobre
los cuales se necesitaba control detallado del proceso de
resolucin de conflictos en intervalos programados.
La aplicacin de gestin de eventos presentaba varias
complicaciones para este proceso. Por ejemplo, el registro de un
participante no est representado en la base de datos mediante una
tabla nica. Esto dificulta la replicacin de informacin que no ha
cambiado ya que el cambio es lo que activa la replicacin de SQL. Se
form un registro lgico del participante, que es un registro que incluye
mltiples tablas de SQL. Cuando ocurra un cambio en cualquier
componente del registro lgico, se produca una transaccin lgica.
Este concepto es importante ya que permite mover informacin al
almacn de datos incluso si no ha ocurrido ningn cambio.
La mayora de las aplicaciones experimentan esta complejidad y es
lo que hace que la replicacin de datos de un lado a otro sea tan difcil.
Eliminamos esta complejidad en la aplicacin de gestin de eventos y
el patrn que seguimos podra implementarse en cualquier aplicacin
desconectada.
Registros lgicos
En el contexto de la aplicacin de gestin de eventos, un registro lgico
para un participante no es la nica informacin dentro de la tabla
Attendee, pero es toda la informacin relacionada. Un registro lgico de
un participante est compuesto de sesiones seleccionadas, compras de
productos y miembros de la familia. Si alguna de esta informacin
cambia, sin importar la tabla en la cual se realiz el cambio, entonces,
el registro lgico del participante tambin ha cambiado.
Un requisito base para esta aplicacin es que si la informacin de un
participante se modifica en el cliente inteligente, ocurre una validacin
Figura 2: La tabla EventDownload especifica los eventos que se
descargarn hacia un determinado host de cliente.
27

Figura 3: Las tablas de historial en tablas principales claves permiten
el mantenimiento de las transacciones
desencadenador se activara y producira un registro de historial. Si un

registro se replica centralmente hacia el cliente inteligente, el
desencadenador se activara, lo que permite tambin asegurar que
haya un registro de historial.
Para poder obtener beneficios de los registros del historial como
transacciones y para admitir el concepto de registros lgicos cuando un
registro se representa en mltiples tablas, es necesario vincular los
registros del historial en las tablas de historial. Este requerimiento dio
como resultado el concepto de transacciones lgicas.
Transacciones lgicas
Una transaccin lgica es una representacin de un participante en
todas las tablas en un momento determinado. Lo que faltaba en las
tablas de historial era un modo de asociarlas. Cuando ocurra un
cambio en una tabla principal, el desencadenador se activara para
completar la tabla del historial respectiva. Ahora se debera modificar el
desencadenador para que desempee las siguientes funciones (Figura
4):
Realizar una copia de la tabla principal e insertarla dentro de la tabla
de historial respectiva (como antes)
Obtener un nuevo ID de transaccin que contenga registro de fecha y
hora
Para cada tabla de historial que representa el registro lgico,
actualizacin del ltimo registro del historial que se insert con un
nuevo ID de transaccin
en todo el registro lgico del participante. Por lo tanto, si slo se

modifica una nica tabla, todos los datos de la tabla que representan
el registro lgico del participante han sido validados como correctos
en ese momento. Esto plantea un problema interesante ya que el
procesamiento estndar de la replicacin de SQL no puede sincronizar
automticamente todos los datos de la tabla relacionados con un
registro lgico si los datos no se han modificado. Resolvimos este
problema al forzar que ocurra un cambio en la base de datos para
que se desencadene un grupo apropiado de eventos, que
denominamos transacciones lgicas para la replicacin de SQL.
Historial de la tabla
La base de datos de la aplicacin de Web existente cuenta con una
tabla de historial asociada con cada tabla modificable del usuario en
la base de datos. El objetivo de estas tablas de historial es mantener
un historial de todos los cambios, cundo se realizaron los cambios y
quin realiz los cambios. Un requisito de la aplicacin de cliente
inteligente es que todos los cambios del historial local se registran y a
continuacin se replican hacia el almacenamiento central de datos.
Todas las tablas del historial se completan mediante un
desencadenador en la tabla principal respectiva. Cada vez que se
realiza una insercin o una actualizacin en la tabla principal, se
produce un nuevo registro del historial (Figura 3).
Las tablas de historial constituyen un historial de cambios de
transacciones para cada tabla, un hecho que se volvi importante
para nosotros cuando consideramos el modo en el que las
actualizaciones para un registro podan replicarse hacia el
almacenamiento central de datos. En vez de replicar un cambio para
un registro hacia el almacenamiento central de datos, como una
actualizacin en la tabla central, podamos replicar los nuevos
registros insertados del historial y reconciliar toda la informacin
centralmente de un modo inteligente.
En nuestro diseo, siempre tendramos al menos un registro en la
tabla de historial. Si se crea un registro en el cliente inteligente, el
28
El tercer punto es importante ya que a pesar de que se realiz un

cambio en una nica tabla y slo se produjo un nuevo registro de
historial, en ese momento, se han validado todas las otras tablas que
representan que el registro lgico. La funcionalidad de obtener un
nuevo ID de transaccin y de actualizar todos los ltimos registros del
historial respectivo se encapsula en una funcin de usuario definida en
SQL y se inserta dentro de cada desencadenador.
Las transacciones lgicas resuelven un problema fundamental que se
presentaba al tratar con informacin que se actualizaba en varios
dispositivos. Este problema surge de la complejidad de sincronizar
mltiples dispositivos en diferentes momentos para la misma
informacin. Consideremos el siguiente escenario:
El dispositivo A actualiza informacin del participante X el lunes y el
dispositivo B actualiza exactamente la misma informacin del
participante X el martes. En esta aplicacin, debido a que se ha
actualizado la misma informacin, la informacin que se actualiz en el
dispositivo B se considera ms importante que la del dispositivo A
porque se actualiz despus. Sin embargo, el dispositivo B se
sincroniza el jueves y el dispositivo A el viernes. En el proceso de
resolucin de conflictos de la tarde del jueves, no se reconocen
actualizaciones del dispositivo A, por lo tanto, se toman las
actualizaciones del dispositivo B. En el proceso de resolucin de
conflictos de la tarde del viernes, se reconcilia la informacin del
dispositivo A. Si no hubiera ningn registro de la fecha/hora de
actualizacin en la transaccin lgica, sera difcil comprender el
momento en el que ocurri el cambio y si la informacin del dispositivo
A es ms o menos importante que la del dispositivo B. Las
transacciones lgicas proporcionaron una representacin clara de la
informacin para todas las entidades de datos en el sistema.
Registros actualizados
Cuando se actualiza un registro de la tabla de SQL, se puede utilizar la
replicacin de SQL para pasar esos cambios de una base de datos a
otra. Parece bastante simple cuando se define de este modo, sin
embargo, saber si se deben sobrescribir los cambios que se tienen con
una actualizacin de otro sistema, no es algo trivial. La regla de el
ltimo en entrar gana no siempre se aplica. Pueden existir partes del
registro que se desean conservar en vez de simplemente
sobrescribirlas.

Registros insertados
Las inserciones de SQL se manejan con
mucha ms facilidad con la replicacin de SQL
ya que no existe, en apariencia, ninguna
resolucin de conflicto que tratar. Sin
embargo, Qu sucede cuando se aade a un
dispositivo desconectado un nuevo
participante que ya existe en algn otro
lugar? En nuestra aplicacin, un participante
podra haberse registrado en la aplicacin en
lnea despus de que se replic la informacin
del evento; en el evento, el participante
podra ser aadido en la aplicacin mvil y
ms tarde, el participante podra trabajar con
otro usuario con su propia instancia de la
aplicacin. Se pueden crear con facilidad
instancias mltiples del mismo registro del
participante.
Comenzamos a pensar en registros que se
haban insertado en el cliente que no tenan la
misma clasificacin que los registros que se
insertaron en el servidor central. Cuando el
registro insertado en el cliente se replicaba en
el servidor, la informacin que contena el
registro deba validarse antes de pudiera ser
accesible para la aplicacin. Para evitar que
estos registros replicados pudieran ser vistos
por la aplicacin ASP.NET, era necesario
etiquetarlos y excluirlos de las consultas de
SQL. El proceso de resolucin de conflictos de
.NET examinara estos registros, determinara
la forma de integrar esta informacin y
decidira si copiar o no la informacin
recientemente insertada dentro de otro
registro, retirara el registro y hara que el nuevo participante estuviera
disponible en la aplicacin de ASP.NET (en nuestro ejemplo).
Para cada tabla SQL que contiene registros que pueden replicarse
desde el dispositivo hacia el servidor central, se aada una nueva
columna para mantener el estado del registro. Cada registro poda
tener uno de los siguientes estados: creado en el servidor, no
reconciliado, combinado, retirado o reconciliado. Si el registro se crea
con la aplicacin de ASP.NET, se etiquetara como creado en el
servidor. Esta etiqueta de estado ayuda a la replicacin de registros
filtrada desde el servidor hacia el cliente. Si se crea un registro en el
cliente, entonces sera no reconciliado. Cuando este registro se
replica en el servidor, su estado es el mismo no reconciliado, lo que
permite identificar el registro para el proceso de resolucin de
conflictos de .NET como un registro que necesita ser procesado. La
aplicacin de Web de ASP.NET ignorar todos los registros que se
encuentre en el estado no reconciliado. Una vez que se procesan, de
acuerdo a la medida que tom el proceso de resolucin de conflictos, el
estado del registro cambiara a combinado, retirado, reconciliado
o desconocido.
Figura 4: Las transacciones lgicas (AttendeeTransaction) mantiene la relacin entre los

registro de historial
Mejorar el modo en que se necesita que los registros actualizados

fluyan dentro de la aplicacin es importante para simplificar lo ms
posible todo el diseo. En el caso de aplicaciones mviles
desconectadas, el flujo de informacin fluye desde un servidor central
y reside y crece de forma temporaria en cada dispositivo
desconectado y finalmente, fluye nuevamente hacia el servidor
central. Al examinar este flujo, realizamos algunas suposiciones y
requisitos sobre el modo en el que funcionara la aplicacin de gestin
de eventos.
La informacin del servidor central slo flua una vez hacia el
dispositivo mvil. Por ejemplo, cuando se requera que un evento
fuera sincronizado y toda la informacin de los participantes se
replicaba hacia el dispositivo, todas las actualizaciones que se
realizaban de la informacin del participante en la aplicacin de Web
en lnea no se replicaran al dispositivo. Incluso si intentbamos
replicar todas las actualizaciones, no podamos basarnos en los
usuarios para volver a sincronizar los dispositivos en el transcurso del
evento. Sin embargo, durante los eventos, los participantes podan
actualizar su informacin en lnea. Nuestro diseo permite que varios
dispositivos y el sistema en lnea actualicen los mismos registros as
como tambin la reconciliacin posterior mediante nuestro proceso de
resolucin de conflictos .NET. Esto es posible si slo se replica lo que
se ha insertado y no actualizado. Slo las inserciones de SQL, y no las
actualizaciones, se comunican entre los sistemas. A continuacin
podemos elegir un momento que prefiramos para reconciliar toda la
informacin de forma central.
En la aplicacin de gestin de eventos, una vez que un evento se
ha replicado en un dispositivo, se puede actualizar un participante
replicado mediante la aplicacin WPF. Cuando se actualiza el registro
del participante, se produce un registro del historial. Con el registro
del historial, se crea una nueva transaccin lgica. Ambos son
inserciones de SQL. Lo que se ha insertado se replica nuevamente
hacia el servidor central. El registro principal en s mismo no se
replica ya que esto sobrescribira el registro en el servidor. El proceso
de resolucin de conflictos de .NET analiza la cola de transacciones
lgicas y determina los nuevos cambios presentes. Examina los
registros del historial que se han producido y determina el mejor
enfoque para integrar esos cambios dentro de los registros
principales.
Resolucin de conflictos con :NET

Los requisitos de la aplicacin mvil de gestin de eventos para tratar
resolucin de conflictos estn fuera del alcance de lo que se puede
tratar con tecnologas listas para usar. Con transacciones lgicas y
estado asociado a registros insertados, nuestro objetivo era tener todos
los datos en un sitio para poder tomar decisiones inteligentes sobre el
modo de tratar la informacin. Parte del misterio es determinar el
momento en el que realmente se deben tomar estas decisiones
inteligentes. Las tecnologas estndares listas para usar toman
decisiones en el momento que se trasladan los registros. Por el
contrario, necesitbamos contar con una visin completa de todos los
registros insertados antes de determinar el modo de reconciliar la
informacin. Se puso en funcionamiento un proceso de negocio que se
ejecutaba en el proceso de resolucin de conflictos de .NET a la 1AM
hora del servidor para reconciliar la informacin replicada del da
anterior.
Cuando se inicia el proceso, obtiene todas las transacciones lgicas
desde el da en el que el proceso se ejecut exitosamente por ltima
29

vez hasta el da anterior a los datos actuales. Un participante puede
estar representado por transacciones lgicas mltiples ya que la
informacin puede haber sido actualizada muchas veces en uno o
varios equipos. Para el caso de mltiples actualizaciones para el
mismo participante en el mismo equipo, slo se procesa el ltimo
ingreso. Para los registros restantes, las transacciones locales se
agrupan por participante y se almacenan por fecha y hora registrada.
A medida que se procesa cada transaccin lgica, se analiza para
saber si el registro del participante se replic o no originalmente
desde el servidor central o si se ingres en el equipo del cliente. Si
originalmente se replic, entonces, los registros del historial han sido
replicados y asociados correctamente. Ahora se pueden implementar
la cantidad necesaria de detalles para determinar las reglas
comerciales que se deben ejecutar en la informacin. Cada registro
lgico al que hace referencia la transaccin lgica posee una o ms
tablas asociadas a l. Podemos decidir simplemente sobrescribir la
informacin ms reciente de todas las tablas, o una o ms tablas o
columnas especficas dentro de cualquiera de las tablas. Todo esto
depende de las reglas comerciales y puede ser tan complejo como
necesario.
Si una transaccin lgica se asocia a un registro de participante
que se cre el en cliente, se debe tomar una determinacin para
saber si el participante ya existe en el sistema. En ese momento, ese
registro no puede ser visto por la aplicacin de ASP.NET porque se
encuentra en el estado no reconciliado. Se construye una clave
compuesta desde los registros del participante para identificarlos
unvocamente. Se examinan los participantes existentes para ver si
existe una coincidencia con el nuevo registro. En ese momento se
toma una de tres vas: el nuevo participante ya existe, es nuevo o la
Figura 5: Columna RecordState aadida para recordar el lugar del

que vino el registro y el modo en el que se proces.
informacin no es suficiente para tomar una decisin. Si el participante

ya existe, todos los registros del historial asociados con el registro del
participante en el estado no reconciliado se actualizan para indicar el
registro del participante preexistente. Las mismas reglas se aplicaban
como si el registro preexistente hubiera sido actualizado. Si el registro
del participante definitivamente es nuevo, su estado cambia a
reconciliado y se pone a disposicin de la aplicacin de ASP.NET. Si
no se puede tomar una determinacin, el estado del registro cambia a
desconocido y se ejecuta una aplicacin de Web de administracin de
excepciones para determinar lo que se debe hacer con el registro.
Este proceso se repite para cada transaccin lgica. Todo el trabajo
realizado fue parte de los preparativos para que el proceso simplifique
esto lo ms posible y centralice toda la complejidad dentro de un nico
sitio.
Conclusin
La construccin de aplicaciones mviles es un desafo. No existe la
estructura mgica que todos podamos utilizar para posibilitar
escenarios desconectados. Contamos con plomera poderosa, pero sin
personalizacin, slo resuelve los escenarios ms simples. El enfoque
que se describe en este artculo es lo suficientemente genrico como
para ser aplicado en diferentes aplicaciones desconectadas. Confiar en
el poder de la replicacin de SQL para realizar slo inserciones nos
permiti focalizar la resolucin de conflictos en el proceso .NET. Si bien
se ha trabajado mucho con los datos para aumentar el esquema de la
base de datos para brindar soporte, creemos que simplific lo ms
posible el proceso de resolucin de conflictos.
Este enfoque no es nuevo y posee limitaciones que lo hacen
adecuado slo para un subgrupo de aplicaciones mviles. Varios
escenarios mviles, por ejemplo, requieren la resolucin de datos en
tiempo real tan pronto como se ha replicado en el servidor central en
comparacin con la cantidad de horas de demora que se proponen en
esta solucin. La replicacin unidireccional de los registros insertados
puede no ser posible, ya que nuestra eleccin aqu ha sido centralizar
el momento y el lugar en el que realizaba la resolucin de conflictos. La
prdida de datos como consecuencia de la resolucin de conflictos
tambin se ha relegado a la intervencin manual en esta solucin.
Aprovechamos el requisito para conservar y replicar todos los cambios
en los registros de forma central, que se transformaron en las
transacciones sobre las cuales basamos nuestro proceso de resolucin
de conflictos. Si no se cuenta con ese requisito, se impone una carga al
replicar ms datos que los que se desea o los que se puede.
Finalmente, el proceso de negocios que orienta la solucin dictaminar
cun caballeroso puede ser con sus elecciones.
Rodney Guzman es CTO y cofundador de InterKnowlogy. Tuvo sus

inicios en los sistemas de software cuando trabajaba sobre las sondas
submarinas en la universidad. Durante siete aos en SAIC, Rodney fue
arquitecto y desarrollador lder en ese tipo de proyectos como un gran
portal de Web basado en Java SOA HTTP/XML sobre hospitales
militares en todo el pas. En 1998, Rodney se traslad a Stellcom para
trabajar sobre ms proyectos de Microsoft, incluidas implementaciones
de Site Server y una estructura de seguridad empresarial para Pacific
Life que permita polticas personalizadas que derivaban de grupos AD
y atributos para orientar la personalizacin y seguridad en sitios de
Web ASP. En InterKnowlogy, Rodney lidera la direccin de tecnologa, y
acta como arquitecto lder en sus proyectos ms grandes; como por
ejemplo una gran implementacin de SOA con una estructura de
cliente inteligente y creacin de amplias propiedades de Web de
Microsoft (CommNet y Partner Campaign Builder) y amplias
implementaciones MOSS. Rodney dise la aplicacin WPF/MOSS
Cancer Scripps. Rodney ha disertado en diversos eventos de Microsoft
y ha escrito numerosos artculos. Ha sido miembro de Comerse PAC y
consejo asesor de arquitectura de Microsoft y es arquitecto de
soluciones MPV.
30
Desarrollo guiado por

pruebas e integracin
continua para
aplicaciones mviles
Por Munjal Budhabhatti
Sntesis
Este artculo demuestra el modo en el que el desarrollo
guiado por pruebas y la integracin continua enfrentan los
desafos nicos que se encuentran al crear aplicaciones para
Windows Mobile.
El TDD es esencialmente desarrollo primero con pruebas +

refactorizacin
Rojo/Verde/Refactorizar, el mantra del TDD, es el orden de las
tareas de programacin:
1.
2.
Estado actual del desarrollo mvil:

Asuntos y desafos
Globalmente, la cantidad aproximada de suscriptores a telfonos
mviles es de 2.5 mil millones. El dispositivo mvil es en la actualidad
una plataforma ms rica para la entrega de aplicaciones debido al
crecimiento vertiginoso y al uso masivo. El factor crtico, como
siempre, es la experiencia de usuario final: rendimiento, confiabilidad
y posibilidad de uso de la aplicacin.
Para complicar las cosas, el mundo del desarrollo de software est
pasando de ciclos de implementacin semanal y mensual a
implementaciones continuas. Por lo tanto Cmo podemos asegurar
que el usuario tenga siempre la mejor experiencia?
Varias personas que han analizado el espacio gil estarn
familiarizados con dos de las prcticas fundamentales de
programacin extrema: el desarrollo guiado por pruebas
automatizadas, un estilo de desarrollo que present Kent Beck
denominado desarrollo guiado por pruebas y una prctica de
desarrollo de software de construcciones que se integran con
frecuencia, denominada integracin continua, como lo plantearon
Matthew Foemmel y Martin Fowler.
Estas prcticas son nuevas en el mundo del software. Sin embargo,
el desarrollo de aplicaciones mviles ha tardado en beneficiarse del
desarrollo guiado por pruebas y la integracin continua que concede
la comunidad de software empresarial. Esto es en parte el resultado
del soporte limitado o no disponible a plataformas mviles en los
conjuntos de herramientas existentes como NUnit/MSTest o
Cruisecontrol.net/Team Foundation Server.
Unas pocas herramientas mviles para pruebas permiten el registro
de las interacciones de usuario a travs de una representacin grfica
del dispositivo de cliente pero no brindan control granular sobre las
pruebas. Otras herramientas pueden ya sea requerir secuencias de
comandos en un dispositivo mvil o prever que se ejecuten pruebas,
de forma manual en el dispositivo. Como resultado, las pruebas en
aplicaciones mviles son ineficaces y complejas y dificultan la
productividad.
Desarrollo guiado por pruebas
El desarrollo guiado por pruebas (TDD) es un enfoque evolutivo en el
que el desarrollo de cdigo est guiado primero, por la escritura de
un caso de prueba automatizado, seguido de escritura de cdigo para
ejecutar la prueba satisfactoriamente y por ltimo, se refactoriza.
3.
Rojo: Escribir una pequea prueba unitaria automatizada que no

pase y tal vez, que incluso no compile la primera vez (Ver Figura
1, pgina 32).
Verde: Escribir el cdigo necesario para pasar la prueba que
fall. Asegurar que las otras pruebas tambin pasen, si estn
presentes, en la serie. Registrar el cdigo en el depsito de
cdigo fuente. (Ver Figura 2, pgina 32).
Refactorizar: Hacer que el cdigo existente sea bonito, en
pequeos pasos graduales, sin cambiar el propsito. (Ver Figura
3, pgina 33).
Por lo tanto, esta tcnica es inversa a la programacin tradicional, el

desarrollo de cdigo seguido de la escritura de una prueba que se
ejecuta ya sea de forma manual o automtica. Por qu aceptar ese
cambio, en especial, cuando uno tiende a pensar que es trabajo
extra? En realidad, el desarrollo guiado por pruebas es programacin
reacia al riesgo, invertir trabajo a corto plazo para evitar fallas (o
incluso ms trabajo) a largo plazo Kent Beck denomin esto una
forma de manejar el temor durante la programacin.
EL DESARROLLO GUIADO POR PRUEBAS ES UNA

FORMA DE MANEJAR EL TEMOR DURANTE LA
PROGRAMACIN TEMOR, NO EN EL SENTIDO
NEGATIVO SINO TEMOR DE UN MODO LEGTIMO. SI
EL DOLOR ES UNA FORMA NATURAL DE DECIR
BASTA!, ENTONCES EL TEMOR ES UNA FORMA
NATURAL DE DECIR CUIDADO!.
KENT BECK
Beneficios del TDD
Mejora de diseo. La escritura de un caso de prueba
independiente exige la creacin de cdigo desacoplado no
estrechamente integrado con otro cdigo por lo tanto aumenta la
cohesin del cdigo y a la vez disminuye el acoplamiento.
Documentacin. Un caso de prueba unitaria bien escrita brinda
una especificacin del trabajo y comunica claramente la intencin
del cdigo. Adems, siempre que el cdigo cambia, el caso de
prueba unitaria debe actualizarse para pasar la serie de pruebas.
Por lo tanto, un caso de prueba unitaria siempre est en sincrona
con el cdigo naturalmente. Esto no es posible con los casos de
pruebas unitarias tradicionales que se desarrollan con Microsoft
PowerPoint o Microsoft Word. Si bien esos documentos
31

Figura 1: Casos de prueba de muestra
namespace OutlookContacts.Tests
{
//Ensure that OutlookContact compares correctly with other contacts.
[TestFixture]
public class OutlookContactTest
{
[Test]
public void EnsureNullContactIsNotEqualToContact()
{
OutlookContact contact = new OutlookContact();
Assert.AreNotEqual(null, contact);
}
[Test]
public void EnsureContactsWithSameNameAreEqual()
{
OutlookContact contactMain = new OutlookContact(foo);
OutlookContact contactOther = new OutlookContact(foo);
Assert.AreEqual(contactMain, contactOther);
}
}
}
comienzan con buenas intenciones, con el tiempo, el resultado

frecuentemente pasa a estar fuera de sincrona con la
implementacin subyacente.
Cambio seguro en el sistema. TDD brinda feedback continuo
respecto de si los cambios realizados en el cdigo funcionaron bien
con las otras partes del sistema.
Falla rpida. La prueba unitaria puede aislar el problema
rpidamente lo que reduce las actividades de depuracin y permite
que el sistema falle rpido.
Cdigo bonito. Cdigo bonito significa cdigo que expresa
claramente su intencin, permite el cambio para aadir
caractersticas y no posee duplicacin. La refactorizacin conserva
la semntica del comportamiento del cdigo, la funcionalidad no se
aade ni se elimina. Se trata de mejorar la calidad del cdigo lo
que aporta valor agregado.
La ejecucin de pruebas unitarias automatizadas es uno de los
Prueba unitaria
Las pruebas habitualmente se consideran un
proceso metdico para probar la existencia o
falta de fallas en el sistema. Cuando se
escribe un caso de prueba antes de escribir el
cdigo, el caso de prueba se vuelve un
requisito, en vez de una simple verificacin de
la caracterstica.
Las pruebas son tambin una forma de
documentar defectos descubiertos.
Supongamos que se descubri un defecto en
control de calidad mientras se probaban bits
implementados recientemente. An si este
defecto se poda corregir de forma muy
trivial, TDD exige un caso de prueba. Primero,
escribir un caso de prueba que simule ese
comportamiento de falla y a continuacin,
escribir cdigo que pase la prueba. Esta
prctica asegurara que los defectos, no
importa cun insignificantes, no se extiendan
en el sistema y la prueba de regresin pase a ser parte de la serie de
pruebas. La ejecucin de pruebas automatizadas de forma local, antes
de ejecutar los cambios en el repositorio de cdigo fuente (SCR),
reducira an ms el fenmeno broken builds.
Es importante preparar el entorno de prueba sobre un emulador lo
ms cerca posible del hardware destino. Desarrollar y probar
aplicaciones Windows Mobile sobre un emulador x86 tiene poco sentido
cuando se tiene como destino hardware exclusivamente para
arquitectura ARM, una arquitectura predominante en la electrnica de
bajo consumo de energa. Adems, en el mundo real, los componentes
por lo general tienen dependencias sobre otros objetos, bases de datos
o conexiones de red. Es muy fcil caer en la trampa de suponer que
estas dependencias funcionan perfectamente. Por lo tanto, si las
pruebas se escriben sin tener en cuenta las dependencias, es posible
que se emita un feedback incorrecto para esas pruebas que fallan
debido a problemas de dependencia.
Una forma de proteccin contra las dependencias es construir el
Figura 2: Cdigo de muestra
namespace OutlookContacts
{
public class OutlookContact : Contact
{
public override bool Equals(object other)
{
if (other == null) return false;
OutlookContact otherContract = (OutlookContact)other;
return otherContract.AccountName == AccountName;
}
}
}
32
requisitos esenciales de TDD. Sin embargo,

debido a que las herramientas de prueba an
estn evolucionando, la ejecucin
automatizada actualmente no es posible en el
desarrollo de aplicaciones mviles. La
implementacin de TDD en este entorno es
por lo tanto, bastante desafiante, aunque no
imposible.
grfico del objeto o establecer la base de datos en un

estado requerido antes de ejecutar el caso de prueba.
Esto resuelve el problema pero aumenta el tiempo de
ejecucin de la prueba y el tiempo de construccin.
Un enfoque ms elegante sera crear instancias de
objetos de prueba y reemplazar la dependencia de los
objetos mediante la implementacin de diseos de
pruebas o cdigo auxiliar objetos que imitan el
comportamiento de los objetos reales. Esto asegura la
ejecucin aislada de la prueba y por consiguiente,
resultados confiables de prueba. Se debe tener
precaucin al imitar objetos reales con diseos de
pruebas o cdigo auxiliar. Es probable que toda la serie
de pruebas unitarias se ejecute de forma perfecta, sin
embargo, el producto podra fallar en la prueba de
control de calidad. He descubierto, por experiencia
propia, que complementar objetos de diseo de pruebas
y cdigo auxiliar con pruebas de integracin brinda un
verdadero sentido de confianza.

Integracin continua
Martin Fowler ha descripto la integracin continua (CI) como una
prctica de desarrollo de software de integracin frecuente de
construcciones, por lo general, varias veces al da. Un flujo de trabajo
de CI tpico, como se muestra en la Figura 4, sera:
Desarrollador:
1. Escribe un nuevo caso de prueba unitaria.
2. Ejecuta el caso de prueba unitaria localmente sobre el emulador y
confirma que el caso de prueba falla.
3. Aade o modifica el cdigo para que pase el caso de prueba.
4. Ejecuta el caso de prueba unitaria localmente sobre el emulador y
confirma que el caso de prueba pasa la prueba.
5. Asigna el cdigo al SCR.
Servidor CI:
6. Descarga el cdigo fuente siempre que haya un cambio en el SCR.
7. Compila e inspecciona el cdigo fuente y crea nuevos binarios.
8. Establece dependencias externas, como esquemas de bases de
datos, y recursos (archivos de configuracin, ensamblados
satlite).
9. Implementa los nuevos binarios y ejecuta las pruebas en el
emulador.
10. Empaqueta e implementa el producto en el entorno de prueba.
11. Genera feedbacks basados en los resultados de la construccin.
Repositorio de cdigo fuente
Todos los archivos principales requeridos para construir un producto
residen en el repositorio de cdigo fuente (SCR). Este repositorio
desempea una funcin importante en el ciclo de vida de desarrollo
de software y CI. Las herramientas SCR, como el control de cdigo
fuente de Visual Studio Team Foundation y Subversion permiten que
los equipos trabajen en forma conjunta: en los mismos o diferentes
artefactos de forma simultnea, realicen un seguimiento de cambios
en el cdigo fcilmente y que trabajen sobre las diferentes versiones
de archivos al mismo tiempo.
El servidor de CI obtiene el ltimo cdigo fuente del SCR, localiza
todas las dependencias necesarias y construye el producto
independientemente de los resultados de la construccin anterior.
SCR permite que el equipo sea ms productivo, un nuevo miembro
del equipo no necesita volver a configurar bibliotecas de terceros,
estructuras de proyectos o configuraciones IDE para el proyecto.
Adems, reduce el tiempo de depuracin lo que permite que el equipo
LA INTEGRACIN CONTINUA ES UNA PRCTICA

DE DESARROLLO DE SOFTWARE EN LA QUE LOS
MIEMBROS DE UN EQUIPO INTEGRAN SU
TRABAJO FRECUENTEMENTE POR LO GENERAL
CADA PERSONA REALIZA AL MENOS UNA
INTEGRACIN DIARIA LO QUE PRODUCE
MLTIPLES INTEGRACIONES POR DA. CADA
INTEGRACIN SE VERIFICA MEDIANTE UNA
COMPILACIN AUTOMATIZADA (INCLUIDA LA
PRUEBA) PARA DETECTAR LOS ERRORES DE
INTEGRACIN LO ANTES POSIBLE. VARIOS
EQUIPOS CONSIDERAN QUE ESTE ENFOQUE
REDUCE SIGNIFICATIVAMENTE LOS PROBLEMAS
DE INTEGRACIN Y PERMITE A UN EQUIPO
DESARROLLAR SOFTWARE CONSISTENTE CON
MS RAPIDEZ.
MARTIN FOWLER
elimine los cambios actuales, lo que sera insignificante y gradual si se
utilizan las prcticas de TDD. El sistema podra volver de forma segura
a la versin anterior del cdigo.
Es fundamental incluir todas las dependencias en el SCR: esto
incluye el SDK para Windows Mobile, el instalador de .NET Compact
Framework, los controladores del servicio de Virtual Machine Network y
otras utilidades y componentes terceros.
Compilacin automatizada
A diferencia de algunos conceptos errneos, la compilacin
automatizada en aplicaciones mviles es mucho ms que una simple
compilacin de cdigo. Ensambla cdigo fuente desde el SCR, compila
cdigo para crear binarios y dependencias (como objetos de
configuracin, ensambles de recursos, etc.), inspecciona e implementa
los binarios compilados hacia un dispositivo mvil o un emulador, carga
esquemas de base de datos y ejecuta pruebas de forma remota en el
dispositivo mvil.
Figura 3: Refactorizacin de muestra
namespace OutlookContacts
{
public class OutlookContact : Contact
{
public override bool Equals(object other)
{
if (other == null) return false;
return CheckEqualityForOutlookContactObject(other);
}
private bool CheckEqualityForOutlookContactObject(object
other)
{
OutlookContact otherContract = (OutlookContact) other;
return otherContract.AccountName == AccountName;
}
}
}
Las herramientas de compilacin, como Nant y

MSBuild no admiten la implementacin de
aplicaciones mviles, en parte debido a que el
soporte de los dispositivos mviles en estas
herramientas es an inmaduro. Adems, las
herramientas para pruebas unitarias, como NUnit y
MSTest poseen un problema similar al ejecutar
pruebas de forma remota en los dispositivos
mviles. Para evitar estas limitaciones, es
fundamental una nueva herramienta.
wMobinium.net
Para tratar estos problemas, compuse una
herramienta wMobinium.net que brinda ayuda en
las implementaciones de TDD y CI en aplicaciones
mviles .NET. wMobinium.net es una herramienta
de prueba unitaria que admite la implementacin
automatizada y la ejecucin de pruebas unitarias
remotas automatizadas. Cuenta con un
complemento de Visual Studio para brindar soporte
33

Figura 4: Integracin continua en una aplicacin de Windows Mobile
.Net
a TDD en aplicaciones mviles .NET. Es una herramienta gratuita

disponible en el sitio de Web de cdigo abierto CodePlex (Ver
Recursos).
Implementacin automatizada
A diferencia del desarrollo de aplicaciones de escritorio, el desarrollo
de aplicaciones mviles enfrenta desafos nicos en la
implementacin: primero, se requiere una implementacin para las
caractersticas de la prueba unitaria en el dispositivo y segundo, es
necesaria la implementacin despus de una compilacin exitosa
para entregar la solucin que funcione en un entorno de prueba para
la prueba de control de calidad.
Para cada compilacin, se deben copiar las dependencias y
binarios recientemente compilados en una carpeta de programa de
un dispositivo. Cuando una aplicacin implica la prueba en
dispositivos mltiples, habr complicaciones aadidas en el proceso
de implementacin. Para evitar esto problemas, wMobinium.net
ofrece una herramienta de implementacin que aplica una Interfaz
de Programacin de Aplicaciones Remotas (RAPI) de Windows CE y
facilita el uso de archivos y carpetas. Esto alivia el esfuerzo de
implementaciones manuales.
Asignaciones frecuentes
Uno de los componentes claves para una implementacin CI exitosa
son las asignaciones frecuentes y en consecuencia, compilaciones
frecuentes. Con intervalos de asignacin ms largos, los miembros
del equipo tienden a trabajar por separado y la compilacin es ms
propensa a problemas de integracin. Cuando un miembro del
equipo dedica ms tiempo a una caracterstica y encuentra
problemas de integracin mientras asigna el cdigo, tiende a ser
reacio a eliminar los cambios y volver a la versin anterior del
cdigo. Esta resistencia puede aumentar la cantidad de tiempo y los
recursos que se dedican en actividades de depuracin. En un
escenario ideal, los miembros del equipo protegen el cdigo en
intervalos de 30-60 minutos o menos. La duracin de la proteccin
podra extenderse unas pocas horas, pero siempre debe durar
menos de un da.
Compilaciones exitosas ms rpidas
Una vez que el desarrollador asigna cdigo hacia el SCR, la espera
de un feedback del CI hace que el proceso de desarrollo sea ms
lento. Las esperas ms largas dan como resultado una productividad
reducida. Adems, algunos de los subprocesos de la compilacin,
como la implementacin y la prueba, se ejecutan en el dispositivo/
emulador, lo que produce que estos procesos sean de por s ms
lentos de lo que hubieran sido en un escritorio.
34
Para reducir los tiempos de compilacin, es necesario concentrarse

en el vnculo ms dbil, el componente que demora ms tiempo en
ejecutarse. Muy a menudo, la causa podra ser una dependencia
externa, como una base de datos u otros objetos. El acceso a una base
de datos y configuracin de datos de prueba para cada caso de prueba
es una operacin que utiliza muchos recursos. Como mencion antes,
los diseos de pruebas o cdigos auxiliares deberan ser tiles. Si no es
prctico hacer esto, se deben trasladar los casos de prueba a las
compilaciones nocturnas o secundarias, compilaciones programadas
que se ejecutan durante la noche cuando la mayora de los recursos
estn inactivos. Los casos de prueba que apuntan a escenarios de
prueba en dispositivos mltiples tambin se deben aadir a las
compilaciones nocturnas o secundarias.
Las compilaciones que fallan causan la mayor frustracin, como si
toda la cadena de produccin de software se hubiera detenido. El
cdigo en el SCR no es ms confiable y el equipo no puede obtener el
ltimo cdigo fuente. El equipo debe resolver el problema rpidamente
mediante la correccin de la compilacin. Si un caso de prueba causa la
falla y la solucin del problema puede requerir una duracin mayor, se
puede ignorar el caso de prueba de forma temporaria para permitir que
la compilacin tenga xito. Sin embargo, es fundamental registrar esos
casos de prueba ignorados en una pared de proyecto de fcil acceso, o
una pizarra fsica o virtual mediante el uso de software colaborativo.
Las pruebas ignoradas deben corregirse ms tarde y agregarse
nuevamente en la serie de pruebas.
Pruebas unitarias automatizadas
Es muy comn ver que los mismos defectos vuelven a aparecer
despus de algunas compilaciones y con frecuencia omos a algn
analista de control de calidad que dice: pero este defecto ya se ha
corregido en una compilacin anterior. Los defectos que vuelven a
aparecer revelan la importancia de escribir una prueba para cada
defecto encontrado antes de modificar el cdigo fuente. Una vez que se
corrigi el caso de prueba, se debe ejecutar toda la serie de pruebas y
todas deben pasar antes de confirmar el cdigo modificado al SCR.
He participado de algunos proyectos en los que el equipo ejecutaba
la serie de pruebas de forma manual en un dispositivo mvil.
Imagnense un desarrollador de aplicaciones mviles que dedica unos
pocos minutos a cambiar la funcionalidad pero tarda el doble de tiempo
para probarla manualmente. Esto no slo desanimar al desarrollador
sino que tambin afectar la productividad.
wMobinium.net resuelve esta molestia mediante la automatizacin
de todo el flujo de trabajo de la prueba unitaria. A diferencia de la
prueba unitaria tradicional, wMobinium.net presenta la seleccin del
caso de prueba en el escritorio, ejecuta las pruebas en el dispositivo y
muestra los resultados en el escritorio. Presta atencin a algunas
complicaciones como las siguientes:
Ejecucin remota de casos de prueba
Para poder ejecutar los casos de prueba de forma remota en un
emulador/dispositivo mvil, la herramienta serializa informacin de
metadatos de los casos de prueba seleccionados, inicia un proceso de
sincronizacin y ejecuta las pruebas en el dispositivo. Para poder
brindar informacin correcta al servidor CI, el proceso remoto debe
iniciarse sincronizadamente y debe monitorearse de forma continua, lo
que es un gran desafo.
Serializacin de resultados de pruebas en el escritorio
A falta de soporte para servicio remoto en la versin 2.0 de .Net
Compact Framework, el dispositivo debe comunicarse con el escritorio
mediante el uso de sockets. El evento debe serializarse, enviarse al
escritorio a travs de un socket, deserializarse y transmitirse a los
manejadores de eventos apropiados.
Complemento de wMobinium.net
Las herramientas que se describen aqu brindan asistencia al servidor
CI para que continuamente compile, implemente y pruebe una
aplicacin mvil .Net. Sera conveniente que la caracterstica de la
prueba unitaria fuera admitida como una herramienta integrada en
Visual Studio.

Figura 5: Complemento de wMobinium.net
El complemento de wMobinium.net, un complemento de Visual Studio

(Figura 5), es una parte del conjunto de herramientas de wMobinium.net.
Una vez que se activa el complemento, todas las pruebas disponibles en la
solucin se muestran en la ventana de herramientas. Un flujo de trabajo
tpico sera:
1. La herramienta de wMobinium.net muestra los casos de prueba
disponibles en una solucin.
2. El usuario selecciona los casos de prueba a ejecutar.
3. Los casos de prueba seleccionados se serializan y se envan al
emulador/dispositivo conectado.
4. Los casos de prueba se ejecutan en el emulador/dispositivo y los
resultados se envan al escritorio.
5. La herramienta muestra los resultados en el escritorio.
Beneficios del uso de CI
Los interesados y los patrocinadores de proyectos siempre prefieren
resultados confiables, comunicaciones claras, visibilidad de proyectos y
calidad de software superior. Sin embargo, el desarrollo de software rara
vez ofrece esas cualidades sin las prcticas y procesos correctos.
Cuando todo parece ir bien, cualquier defecto puede de repente poner en
peligro la planificacin del desarrollo. En especial durante interacciones
Big-bang, incluso pequeos problemas como la falta de registros de
configuracin, bases de datos desactualizadas o falta de dependencias
podran ser extremadamente perjudiciales cuando se encuentran todas
juntas.
La integracin continua permite un feedback ms rpido. En cada
cambio, agregar nuevas caractersticas o modificar las existentes, sin
importar cuan grandes o pequeas, el servidor CI integrara las nuevas
partes que pasaran a travs del todo el ciclo de compilacin automtica:
compilacin, prueba, inspeccin e implementacin. Esto proporciona
visibilidad del progreso del proyecto, mejora la calidad del software
desarrollado y aumenta la moral del equipo.
CI no brinda estas funcionalidades listas para usar. Es muy posible
implementar CI sin incluir pruebas automatizadas o inspeccin en el
proceso de compilacin; sin embargo, esa configuracin sera la menos
beneficiosa. Varias personas, incluyndome, consideramos que CI sin
pruebas, no es CI.
Conclusin
Desde la perspectiva del usuario, la implementacin de
TDD y CI es igual en una aplicacin de escritorio
tradicional y en una aplicacin mvil. El usuario crea un
caso de prueba automatizado defectuoso, escribe el
cdigo para que pase la prueba y refactoriza el cdigo
sin cambiar la intencin. El servidor CI consulta el
ltimo cdigo fuente, crea nuevos binarios, ejecuta las
pruebas y genera el feedback. Sin embargo, en una
aplicacin mvil la implementacin difiere en la
ejecucin remota de casos de prueba, notificacin de
resultados de pruebas e implementaciones de
compilaciones. Estas complejidades se tratan con la
herramienta de wMobinium.net.
En mi experiencia pasada en una de las ms grandes
organizaciones microfinancieras de frica, mi equipo y
yo desarrollamos una aplicacin mvil .Net. A falta de
herramientas de soporte, el desarrollo que implement
TDD y CI, aunque fue difcil, mejor todo el desempeo,
confiabilidad y diseo de la aplicacin.
Con el lanzamiento de la versin 2.0 de .Net Compact
Framework, el desempeo de la aplicacin mvil .Net
mejor radicalmente. La versin ms nueva brinda
productividad del desarrollador mejorada, mayor
compatibilidad con el.Net Framework completo y
soporte mejorado. La combinacin de .Net Compacto
Framework con TDD y CI (mediante el uso de wMobinium.net)
aportara mayores beneficios a una organizacin y llevara la
plataforma de la aplicacin mvil al prximo nivel.
Con la proliferacin de los nuevos dispositivos mviles en la
actualidad, la aplicacin mvil se est convirtiendo en una parte
fundamental de una ms amplia oferta de productos empresariales.
Es pragmtico, ms que nunca, sacar el desarrollo de aplicaciones
mviles del aislamiento e incluirlo en los esfuerzos de integracin
continua y desarrollo guiado por pruebas en toda la empresa.
Recursos
Continuous Integration, Martin Fowler y Matthew Foemmel
http://www.martinfowler.com/articles/continuousIntegration.html
Continuous Integration: Improved Software Quality and Reducing
Risk, Paul Duvall, Steve Matyas, y Andrew Glover (Addison-Wesley
Professional, 2007)
Test-Driven Development: By Example, Kent Beck (Addison-Wesley
Professional, 2002)
wMobinium.net
http://www.codeplex.com/wMobinium
Sobre el autor
Munjal Budhabhatti es desarrollador de soluciones senior en
ThoughtWorks. Cuenta con ms de 10 aos de experiencia en el
diseo de aplicaciones empresariales a gran escala y ha
implementado soluciones innovadoras para algunas de las ms
grandes organizaciones financieras, de seguros y microfinancieras en
frica, Asia, Europa y Amrica del Norte. Dedica la mayor parte de su
tiempo a escribir aplicaciones empresariales bien diseadas mediante
el uso de procesos giles.
35
Estudio de un caso:
Brindar asistencia a los
tcnicos en el campo de
operacin
Por Andrs Velvrt y Peter Smulovics
Sntesis
Monicomp es el mayor responsable de mantenimiento de
equipos para bancos en Hungra. La organizacin instala,
mantiene y repara terminales de Puntos de Servicio (POS).
Los cajeros automticos (ATM) y otros equipos para bancos
similares, utilizan cientos de tcnicos distribuidos en todo el
pas. Cualquier compaa que necesita realizar estas tareas y
debe seguir la norma ISO 9000 necesita toda la ayuda
posible de TI. La organizacin debe realizar un seguimiento
para verificar cada metro utilizado en un de cable de dos
kilmetros, por lo tanto, si existe un problema con el cable,
puede dirigirse a todos y cada uno de los comercios en los
que el cable se ha utilizado y realizar las reparaciones
necesarias antes de que surjan los problemas. Adems, los
clientes solicitan informacin actualizada en la Web, que
vara desde saber si las actualizaciones de software en todo
el pas se realizan bien hasta la terminal POS defectuosa del
comercio de mascotas del Sr. Smith.
Como es de suponer, una forma de trabajar basada en el
papel no puede satisfacer estos requisitos. Sera poco
realista para los tcnicos ir al lugar de trabajo y enviar las
planillas para que se procesen al final de la semana laboral.
Se necesita una solucin del siglo XXI. El sistema MVSZ,
desarrollado por una compaa consultora y de desarrollo de
software llamada Response, abarca toda las posibilidades de
operacin del servicio desde el inventario hasta la
facturacin; desde notificacin de problemas hasta
distribucin y verificacin del trabajo para ms de 100
tcnicos que desempean tareas de mantenimiento e
instalacin. En este artculo, mostraremos el modo en el que
se disea la arquitectura de este sistema y describiremos los
desafos y soluciones en la creacin de subsistemas mviles.
Tipo de planilla que categoriza el trabajo a realizar: instalacin,

reparacin o desinstalacin
Una referencia para el par o direccin en la que se debe realizar el
trabajo
Informacin de la notificacin de problemas original que registr el
operador (si existe)
Identificadores y datos adicionales de los dispositivos que se deben
instalar o desinstalar
Identificador de la planilla misma
Plazo del trabajo
Asignacin de la planilla. Para iniciar el flujo de trabajo, el
operador asigna la planilla a un tcnico despus de haber analizado
la carga de trabajo y la posicin geogrfica del tcnico disponible.
Para facilitar esta tarea, la posicin geogrfica de los tcnicos se
obtiene a travs del Sistema de Posicionamiento Global (GPS)
mediante el rastreo de los dispositivos y se muestra en un mapa
integrado de Virtual Earth, con conos codificados con colores que
indican sus cargas de trabajo en ese momento. (Ver Figura 1).
Descarga de la planilla. Una vez que se ha asignado la planilla a
un tcnico, se le enva un mensaje de SMS (Short Message Service).
El SMS notifica al tcnico y al dispositivo de la PC Ultramvil (UMPC)
que hay un nuevo trabajo por realizar. Mediante la sincronizacin del
General Packet Radio Service (GPRS), Edge, 3D o
Figura 1: Uso de Virtual Earth Services para seleccionar el tcnico

que se encuentra ms cerca del destino con la menor cantidad de
trabajo asignado.
Flujo de trabajo de las planillas

Antes de analizar la visin global de la arquitectura para la aplicacin,
comencemos con una visin general de los procesos importantes de
trabajo en la organizacin. Para Monicomp, la entidad ms importante
en un flujo de trabajo mvil es la planilla. La planilla es un elemento
de trabajo que debe realizar un tcnico en el campo de operacin.
Examinemos los conceptos claves de un flujo de trabajo simplificado:
Creacin de una planilla. La planilla, por lo general, la crea el
operador. Cuando se crea una planilla, contiene los siguientes
atributos claves:
36
Tcnicos en el campo de operacin

una red inalmbrica, de acuerdo a la disponibilidad
del rea en la que se encuentra el tcnico, se
descarga la planilla en la aplicacin Planilla que se
ejecuta en la UMPC.
Figura 2: Visin general de los componentes principales y sus enlaces de comunicacin

Cliente UMPC
UMPC
Windows Presentation Foundation

Tinta muy eficaz
Servicios de
informacin
SQL Server Compact

Completar la planilla. El tcnico estudia la planilla
Manuales con News Reader SDK & Comentarios
que recibi, viaja hacia la ubicacin en la que se
Fotografas y anotaciones, dictado
debe realizar el trabajo y realiza el trabajo. Durante
Comando de voz
de ADO.Net
Virtual Earth
el trabajo de reparacin, instalacin, mantenimiento
WCF
Firmas (todava no por asuntos legales)
o desinstalacin, el tcnico registra los detalles del
REST/POX
dispositivo sobre el cual trabaja (por ejemplo,
3G
Cliente rico Intranet
nmero de serie) y asigna equipos y materiales
desde el inventario de su dispositivo. Tambin
Uso compartido de Windows Forms y
puede utilizar la aplicacin de la planilla para
Windows Presentation Foundation
Astoria
ClickOnce
analizar especificaciones tcnicas del dispositivo
Virtual Earth
sobre el que se trabaja si llega a suceder que la
de ADO.Net
reparacin se dificulta. Estas especificaciones
Cliente Web Extranet
SQL Server 2008
tambin se pueden anotar con tinta, y esas
Caractersticas de ASP.Net AJAX
anotaciones se comparten en la base cognitiva.
Caractersticas de ASP.Net - Jasper
Windows Server 2008
Otros datos que se deben registrar incluyen la
Aprobaciones de flujo de trabajo Web
hora de llegada al lugar de trabajo, la cantidad de
Silverlight
horas que dedic el tcnico o los tcnicos para
realizar el trabajo y la distancia de desplazamiento hacia y desde la
ocasionalmente. Dado esto, Cmo se planifica una arquitectura para
ubicacin. Pueden obtener ms detalles sobre la aplicacin de la
un escenario ocasionalmente conectado?
planilla en la seccin Interfaz de usuario con WPF que se encuentra
En esta seccin, resumimos algunos de los problemas claves que
ms adelante en este artculo.
enfrentamos al planificar e implementar esta arquitectura mvil, de
alta complejidad. Para comenzar, analicemos la Figura 2, que muestra
Finalizacin de la planilla. Una vez que se ha completado la
los vnculos de comunicacin y componentes principales de nuestra
planilla, se imprime en una impresora mvil y el cliente la firma. La
arquitectura mvil.
firma tambin podra capturarse en la pantalla sensible al tacto de la
UMPC mediante el uso de tinta digital (para que el tcnico no tenga
Ocasionalmente conectada
que llevar impresiones con l), sin embargo, debido a cuestiones
La principal consideracin para una arquitectura ocasionalmente
legales, esta funcionalidad todava no se ha utilizado.
conectada es la sincronizacin, sea unidireccional, bidireccional o que
trata con lgica de resolucin de conflictos y presenta esto a travs de
Transferencia de la planilla. La base de datos de la UMPC est
la interfaz del usuario. Si no se tratan estos problemas pueden surgir
sincronizada, de modo que transfiere los cambios que se realizan en
problemas de consistencia; resolver los problemas hace que la lgica
la planilla hacia el servidor central. La lgica de negocios del servidor
de negocios sea mucho ms complicada que un simple escenario en
registra el trabajo que se realiz, elimina del inventario del tcnico,
lnea o sin conexin. Para reducir el tiempo de salida al mercado,
los materiales que se utilizaron y realiza cualquier otra tarea de
seleccionamos los servicios de sincronizacin de ADO.NET, que se
reorganizacin necesaria. El mecanismo de sincronizacin tambin es introdujeron junto con otras partes del conjunto de herramientas para
muy til para crear copias de seguridad actualizadas de las bases de
crear una solucin completamente automatizada, menos propensa a
datos de los tcnicos. Si una UMPC se daa o se pierde, el tcnico
error y estandarizada.
puede rpidamente reanudar su trabajo ya que su base de datos se
puede volver a crear del mismo modo en el que se encontraba en el
Componentes claves del sistema
momento de su ltima sincronizacin.
En el corazn del sistema existe un servidor de aplicacin de mltiples
capas, que realiza el almacenamiento de datos y funcionalidad de la
Dos tipos de sincronizacin
lgica de negocios. Diversos tipos de clientes diferentes utilizan estos
Los clientes de las UMPC pueden realizar dos tipos de sincronizacin.
servicios:
Para ahorrar ancho de banda y la vida til de la batera, la
sincronizacin rpida slo transfiere los datos directamente a la
Una aplicacin de formularios de Windows que utilizan en la sede
planilla del tcnico. La sincronizacin completa (doking) descarga el
central los encargados de depsito, operadores y tcnicos que
grupo completo de datos hacia la UMPC, por ejemplo, cambios en el
realizan tareas de reparacin que no se pueden llevar a cabo en la
personal o actualizaciones de software; por lo tanto, por lo general se
empresa. La aplicacin se implementa mediante el uso de ClickOnce,
realiza a travs de una conexin a Internet en la casa del tcnico.
lo que ayuda a asegurar la actualizacin de las versiones sin
problema.
Esquema general de la arquitectura - Qu? y Por qu?
Una aplicacin Web de extranet con interfaz receptiva y fluida que
La arquitectura, ya sea en la definicin de conexiones entre cajas
utilizan los ms grandes clientes para realizar cientos de pedidos en
blancas y negras, visualizacin de caracteres en una lnea de
un nico lote, organizar por orden de importancia y realizar un
comandos, llamadas a servicios de Web o uso de una Aplicacin de
seguimientos de esos pedidos.
negocios basada en Office, est, por naturaleza, determinada por el
Una aplicacin de Windows Presentation Foundation que se ejecuta en
tipo de calidad de la conexin. La informtica mvil, a pesar de la
cientos de UMPCs que utilizan los tcnicos que realizan tareas de
ideologa actual siempre conectado, en realidad est conectada
instalacin, reparacin y mantenimiento en todo el pas.
37

Configuracin del servidor
Como un servidor backend, descubrimos que el nuevo Windows
Server 2008 era una solucin ideal para escenarios de Software +
Servicios como ste, fundamentalmente porque es capaz de alojar
servicios de Windows Communication Foundation (WCF) para que
atiendan y coloquen en cola de espera solicitudes HTTP en el nivel
kernel, que al mismo tiempo es fcil de administrar desde una
perspectiva de infraestructura.
Utilizamos una instancia de SQL Server 2008 que se ejecutaba en
el servidor para brindar capacidades como almacenamiento de datos
espacial y para servir como almacn de datos en cuanto a solucin
de sistema de informes para la aplicacin del operador y el sitio de
Web externo. Los problemas de sincronizacin que se mencionaron
anteriormente se trataron a travs de ADO.NET Syncronization
Services, junto con la solucin de Microsoft Base de datos en la
Nube, denominada Astoria, sobre la cual se puede obtener
informacin en la edicin 13 de The Architecture Journal. Con el uso
de Astoria, creamos un servicio de WCF y a travs del servicio,
mediante el uso de los protocolos de Representational State Transfer
(REST) y Plain Old XML (POX), lemos y modificamos la base de
datos subyacente. Para establecer la lgica de negocios necesaria en
los lugares adecuados, descubrimos que los desencadenadores de la
base de datos, Astoria y los servicios de sincronizacin funcionaban
bien juntos.
Aplicacin de facturacin, almacenamiento y operador
Para colaborar con el trabajo de los encargados de almacn, lderes
de grupo y operadores en la sede central, se necesitaba una
aplicacin fcil de usar para que toda la informacin necesaria
estuviera disponible al instante. Esta aplicacin de Lnea de Negocios
(LOB) se integra con los sistemas de posicionamiento (mediante el
uso de almacenamiento de datos espacial), crea una buena
experiencia del usuario (a travs de una combinacin de WPF y
Windows Forms) y muestra mapas (con el uso de los servicios de
Virtual Earth Live).
Sitio de Web externo
Debido a que esta era una solucin nueva, tenamos cierta
flexibilidad para analizar tecnologas sin incurrir en grandes riesgos
de tener que administrar todas la aplicaciones existentes.
Implementamos un paso de flujo de trabajo personalizado para
poder aprobar, rechazar o modificar registros que eran visibles para
el usuario final, fundamentalmente, para evitar mostrar datos
desactualizados. La solucin para esto deriv de Windows Workflow
Foundation Web Workflow Approvals Starter Kit, que poda
personalizar con poco esfuerzo. Otra oportunidad para ampliar el
horizonte de la tecnologa fue el desarrollo rpido de prototipos que
ofreca la solucin de andamiaje Jasper que vena con
caractersticas de ASP.NET: comenzamos con una interfaz simple,
Figura 3: Se lleva al usuario inmediatamente a la parte ms usada

de la aplicacin
38
descubrimos que era fcil tratar la personalizacin en profundidad sin

perder la inversin en los formularios originales. El soporte de historial
y el botn de retroceso fcil de usar de las caractersticas de ASP.NET
Ajax permitieron que los cambios en las interfaces sean fluidos.
Aplicacin de la UMPC
Descubrimos que la aplicacin creada para el dispositivo de la UMPC
era nuestra oportunidad para aadir el pensamiento ms innovador. El
dispositivo de la UMPC y la aplicacin de la planilla desempean
diferentes tareas:
Registro del trabajo realizado por el tcnico, por lo tanto, completa la
planilla
Comunicacin con el servidor a travs de 3G, Edge o WiFi, mediante
el uso de los servicios de sincronizacin de ADO.NET y una instancia
local de SQL Server 2008 Compact Edition para el almacenamiento de
datos
Registro de voz y cmara para la documentacin con comentarios
adicionales va tinta
Exhibicin de manuales en formato XPS mediante el uso de Microsoft
News Reader SDK para cajeros automticos y puntos de servicios,
capacidad de colaboracin y comentario de caractersticas, con
navegacin basada en lpiz, botn suave o voz.
Exhibicin de informacin de mapas y rutas para el prximo destino a
visitar.
Cul es la infraestructura que esto implica? Desde el lado del
desarrollador, era cuestin de agrupar bloques de construccin bien
definidos, como Enterprise Library, WPF, ADO.NET Synchronization
Services, SQL Server 2008 Compact Edition, WPF y el .NET Framework.
Debido a que la UMPC es una PC completa con un procesador
compatible con x86, sistemas operativos de ejecucin familiar como
Windows XP Tablet PC Edition o Windows Vista, descubrimos que el
proceso real de desarrollo es muy parecido al desarrollo de una
aplicacin de escritorio normal. Sin embargo, desde el lado de la
ergonoma del software y el diseador nos dimos cuenta que el
desarrollo era un poco ms complejo. Exploramos esto en la prxima
seccin.
Interfaz de usuario con WPF
Abandonar la interfaz de usuario tradicional
Windows Presentation Foundation brinda a los diseadores de IU la
posibilidad de reconsiderar viejos hbitos de diseo de IU y ofrece la
oportunidad para algn pensamiento lateral, creativo.
Si hubiramos tomado una visin tradicional de la IU,
probablemente, habramos enumerado las funciones del software,
creado grupos y a continuacin exhibido un men principal despus de
que el programa se hubiera iniciado, muy probablemente, con las
Figura 4: Al abrir la carpeta se obtienen detalles adicionales y acceso a

la edicin de sus contenidos.

Figura 5: El inventario siempre se accede sobre el lado derecho
Figura 6: Los mens de torta son ideales para aprovechar la memoria

espacial. Las grandes reas sensibles al tacto ayudan con la interaccin
del dedo.
opciones utilizadas con ms frecuencia primero. Sin embargo,

decidimos eliminar todo el men principal, el software se inicia en la
vista ms usada con la pantalla general de la planilla. La funcin
adicional de sincronizacin, actualizaciones de versin, repositorio de
referencias y acceso al inventario del usuario se implementaron como
paneles desplegables complementarios.
En la pantalla general de la planilla, las planillas se visualizaban
como carpetas. Las carpetas ya mostraban los datos ms importantes
en el exterior (Figura 3), pero los detalles adicionales se mostraban
cuando se abra una carpeta al tocar ligeramente la pantalla sensible
al tacto (Figura 4). Tambin colocamos el botn Editar Planilla en el
interior de la carpeta, y de este modo aseguramos que no se abrieran
las planillas para edicin sin que el usuario haya tenido la oportunidad
de analizar los detalles.
editor de la planilla (Figura 6). Nos dimos cuenta que la primera vez los
usuarios rpidamente comprendan el modo en el que funcionaba el
men con ayuda de animaciones rpidas, sutiles que se mostraban al
abrir el men, submen o seleccionar una opcin del men. Las reas
sensibles amplias del men ayudaban cuando el men se utilizaba con
un dedo, el dedo no es muy preciso comparado con un mouse o un
lpiz, pero siempre est disponible. El men de torta tambin
aprovecha la memoria espacial del usuario ya que es mucho ms fcil
recordar que el cono Cerrar Planilla est sobre el lado derecho que
recordar que es la tercera opcin del men desplegable.
En la vida real, la colocacin de los elementos es un modo de
organizarlos y queramos llevar este concepto a la interfaz del usuario.
Por ejemplo, uno puede tener la costumbre de conservar los
documentos importantes sobre el lado izquierdo del escritorio, y los
que son menos importantes, sobre la derecha. Hemos ofrecido lo
mismo para nuestros tcnicos en el esquema de la planilla: las carpetas
se pueden mover, rotar e incluso cambiar el tamao (Figura 7).
Aprovechar la memoria espacial

Segn Wikipedia, la memoria espacial es la parte de la memoria
responsable de registrar informacin sobre el propio entorno y en su
orientacin espacial. Por ejemplo, la memoria espacial nos ayuda a
Interaccin natural
recordar que hemos visto el lpiz que estamos buscando en la parte
Por muy acostumbrados que estemos al mouse, no es un modo natural
derecha de la mesa.
de interaccin. Uno debe mover un objeto de forma extraa en el
Si se aprovecha la memoria espacial, y siempre se ponen las
escritorio, mientras mira por todas partes para ver si el cursor ha
mismas cosas sobre el mismo lado de la pantalla, los usuarios
recordarn instintivamente dnde encontrarlas. Para
implementar esto en nuestro caso, el panel inferior
Figura 7: La ubicacin de carpetas personalizables permite el agrupamiento
desplegable contiene materiales de referencia y el panel
espacial para que se adapte a los hbitos del usuario individual.
desplegable del lado derecho contiene el inventario, todos
los equipos que tienen en la parte trasera de sus camiones,
listos para usar cuando instalan o reparan dispositivos
(Figura 5).
El panel del inventario posee dos funciones:
Inicialmente, el tcnico verifica si tiene los repuestos con
l. A continuacin, cuando completa la planilla, registra las
partes que ha utilizado para la reparacin arrastrando y
soltando artculos desde el inventario hacia la planilla. En
ambos casos, el inventario se puede encontrar sobre el lado
derecho, se puede acceder, filtrar y organizar del mismo
modo. Hemos elegido el lado derecho porque, durante
pruebas al usuario, descubrimos que la mayora de los
tcnicos son diestros, por lo tanto, toman la UMPC con la
mano izquierda y el lpiz con la mano derecha. Al ser este
el caso, la operacin de arrastrar y soltar necesaria para
aadir un artculo desde el inventario hacia la planilla era
ms conveniente.
Elegimos incluir un men de torta en la pantalla del
39

Un buen ejemplo es el campo en el que ellos registran la cantidad de
horas que dedicaron en las reparaciones. Nos dimos cuenta que el
usuario deba sealar (hacer un clic) el cuadro de texto adecuado,
seleccionar su contenido, si exista, hacer un clic para abrir el teclado
en pantalla, ingresar la cantidad de horas y cerrar el teclado. Esto
implica cinco clics y mucho cambio de contexto en la mente del usuario
(Deseo ingresar un nmero. Debo seleccionar el lugar en el que lo
quiero. Necesito abrir en pantalla un teclado virtual. Debo utilizar el
teclado, cerrar el teclado y regresar a la tarea principal de completar la
planilla). Comparemos esto con la accin de escribir el nmero 3 con
un lpiz en el campo adecuado (Figura 6) y uno valorar la simplicidad
natural de esta nueva-antigua forma de interaccin.
Figura 8: En el espacio para dibujar, el tcnico puede registrar

cualquier tipo de informacin grfica.
llegado a la posicin deseada. Cuando se trata de interacciones como

seleccionar y pulsar, arrastrar y soltar o dibujar, el uso de una
pantalla sensible al tacto es mucho ms intuitivo y productivo, incluso
para usuarios diestros con el mouse. Sin embargo, habiendo dicho
esto, un dedo o incluso un lpiz o un estilete tienden a ser mucho
menos precisos que el mouse. Para incorporar esto cuando diseamos
la interfaz del usuario, preferimos mantener botones grandes y
asegurarnos que no se toquen entre s. Por el mismo motivo, cuando
utilizamos una barra de desplazamiento, debimos asegurarnos que
fuera ms ancha de lo normal.
Durante nuestras experimentaciones con los usuarios, descubrimos
que la barra de desplazamiento es algo que en realidad no se desea
tener en un entorno de pantalla sensible al tacto. Si uno piensa en
esto, el uso de una barra de desplazamiento es algo poco natural, se
debe presionar una flecha hacia abajo o arrastrar un pulgar pequeo
hacia abajo, cuando uno desea que el contenido a desplazar se
mueva hacia arriba. Cuando uno desplaza un documento, en realidad
se debe mover en direccin opuesta a la del mouse o rueda de
desplazamiento. Una forma mucho ms natural de desplazamiento es
arrastrar el contenido mismo en la direccin que uno desea moverlo.
Olvidar este modo poco natural de desplazamiento es parte de lo que
hace que el uso de la generacin ms reciente de dispositivos mviles
sea tan divertido.
Uso de tinta para ingresar datos
Cuando se trata de registrar informacin, nos dimos cuenta de que,
desde el punto de vista de la utilidad, nada supera la versatilidad de
un lpiz y un papel. El uso de tinta brinda a los tcnicos uno modo
libre de dibujar diagramas, escribir texto o comentar partes de un
documento. En el mundo digital, las Tablet PCs, UMPCs y PCs de
bolsillo que poseen pantallas sensibles al tacto pueden funcionar de
un modo similar. Encontramos que el uso de tinta digital era til para
la creacin de dibujos, comentarios y para el registro de la firma del
cliente que confirma que el trabajo se ha realizado.
El uso de Ink API en Windows Presentation Foundatios (en el
espacio de nombres System.Windows.Ink) hizo que el uso de tinta
digital sea algo fcil en los escenarios descriptos ms arriba. En slo
algunas horas, pudimos aadir el espacio para dibujar con capacidad
para almacenar, editar y cambiar el tamao de los trazos de tinta, y
la mayor parte del tiempo la dedicamos a la creacin de conos que
cambian entre los modos de dibujo. (La Figura 8 muestra un ejemplo
de una imagen con comentarios). El reconocimiento de texto, o
anlisis de tinta, es tambin muy simple y funciona para varios
idiomas, incluidos ingls (UK o US), francs, espaol, coreano,
alemn, japons o chino.
Sin el uso de anlisis de tinta, el modo en el que el tcnico
completa el formulario sera bastante difcil sin un mouse o un
teclado.
40
Conclusin
La creacin de aplicaciones mviles conectadas ocasionalmente
presenta varios desafos. Afortunadamente, las tecnologas de
hardware y software que posibilitan esas aplicaciones estn
comenzando a ser ms convencionales: UMPCs con capacidades de
hardware de PCs desde hace unos aos, rastreadores de GPS,
conectividad a Internet mvil, bibliotecas de software sofisticadas,
reconocimiento de voz y tinta incorporados al sistema operativo, y
mltiples servicios en lnea; la lista contina. Con el sistema que
preparamos para Monicomp descubrimos que todo se integraba bien; lo
que permiti a los desarrolladores construir soluciones mviles que slo
se atrevan a imaginar hace una dcada los escritores de ciencia
ficcin.
Sobre los autores

Andrs Velvrt trata el desarrollo de software al estilo Lincoln:
Tengo seis horas para talar un rbol. Utilizar cuatro horas para afilar
el hacha. En el pasado, fue uno de los pocos que ayud a difundir la
idea de la World Wide Web en Hungra. Siempre ha disfrutado probar e
implementar las ms nuevas tecnologas, varias de sus pruebas de
conceptos terminaron siendo contribuciones tiles para proyectos,
desde el lado de IU/Usabilidad hasta el lado del proceso de desarrollo.
Ha trabajado con tecnologas de Microsoft por 12 aos. Fue
desarrollador lder, arquitecto y gerente de proyecto en varios
proyectos empresariales, de escritorio y de Web, hasta que fund su
propia empresa de consultora y desarrollo de software, Response. Se
lo puede contactar en andras.velvart@response.hu.
Peter Smulovics es un muchacho de Microsoft que busc la aguja en
el pajar por ms de 10 aos. Trabaj sobre proyectos como SQL 2005
Analysis Services, Visual Studio.Net 2005, Microsoft Business
Framework y Portal, ADO.Net Entity Framework, Dynamics Great Plains
y Solomon, en los que realiz pruebas, desarrollo, lider grupos y
dise. Mientras tanto, fue parte de grupos de usuarios, se present en
Developers Days, TechEds y foros de Microsoft, lider la presentacin
de .NET en el pas, todas estas actividades fueron parte de su rutina
diara. Actualmente, trabaja en el grupo Development and Platform
Adoption y brinda ayuda de arquitectura y seminarios para clientes
empresariales sobre varios productos diferentes. Se puede contactar a
Peter en smulovics.peter@microsoft.com.
Exencin de responsabilidad: Si bien la solucin que se describe en
este artculo est basada en el actual sistema de trabajo de Monicomp,
debido a la naturaleza del tema, se han cambiado algunos detalles para
proteger los intereses de la compaa, mientras que otros se
encuentran actualmente en la etapa de planificacin e implementacin.
098-108819
Suscrbase en www.architecturejournal.net

The Journal Architecture N 14

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

The Journal Architecture N 14

Hochgeladen von

Copyright:

Verfügbare Formate

Aprenda la disciplina,

Por Simon Guest

Consideraciones de arquitectura para un mundo de

Por Atanu Banerjee

Mejores prcticas: extensin de aplicaciones empresariales

Por Kulathaumani Hariharan

Descubra mejores prcticas y recomendaciones para la extensin de aplicaciones empresariales hacia

Experiencia de consumidor conectada en

Por Christoph Schittko, Darryl Hogan y Jon Box

Perfil del Architecture Journal: Faisal Waris

Arquitectura de datos mviles

Por Rodney Guzman

Desarrollo guiado por pruebas e integracin continua para

Por Munjal Budhabhatti

Estudio de un caso: Brindar asistencia a los tcnicos en el

Por Andrs Velvrt y Peter Smulovics

que sirven de base. www.architecturejournal.net

La informacin contenida en The Arquitecture

Todos los derechos del autor, marcas registradas y

2007 Microsoft Corporation. Todos los derechos

THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net

Nuevas oportunidades con dispositivos

consumidores disminuyeron un 4 por ciento ya que se desperdiciaba

www.architecturejournal.net - Journal 14 THE ARCHITECTURE JOURNAL

Mensajes (Correo electrnico, IM, SMS, Voz)

los corredores de todo el mundo puedan formar grupos y ver los

La convergencia conduce a una segunda tendencia: Los dispositivos

THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net

Conexin con amigos

Experiencias relacionadas con el usuario

A diferencia de las PCs, consideran a los dispositivos como

www.architecturejournal.net - Journal 14 THE ARCHITECTURE JOURNAL

Los dispositivos tienen recursos limitados. A medida que los

con capacidades muy limitadas.Para experiencias ricas de

Figura 4: Estructura conceptual para la aplicacin de Software +

Solicitudes /mensajes de control

Tecnologas sensibles al tacto. Algunos dispositivos utilizan

THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net

Global) que cumple su funcin basado en una red de tres o ms

Software ejecutable en el dispositivo

Sistema operativo del dispositivo.

El sistema operativo se debe seleccionar de acuerdo al uso que se le

protegida de 32-bits, en tiempo real, que es compatible con una gran

Figura 5: Opciones de desarrollo para la construccin de interfaces de aplicacin en un

Canales de acceso para dar soporte a los

www.architecturejournal.net - Journal 14 THE ARCHITECTURE JOURNAL

Figura 6: Uso de tecnologas de reconocimiento de voz en Microsoft Office

de consultas para la bsqueda;a continuacin, los resultados se

Servicios para brindar soporte a dispositivos

Servicios de aplicaciones y soluciones. Ofrecen servicios especficos

Los servicios del segundo y tercer nivel representan capacidades

THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net

calendario estaran disponibles ya sea desde otros dispositivos mviles

www.architecturejournal.net - Journal 14 THE ARCHITECTURE JOURNAL

que las redes de entrega de contenido trasladen los datos y tambin

Safaricom: On a Tear in Africa por Jack Ewing, 27 de agosto de 2007,

THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net

Sin una conexin, la aplicacin mvil no funciona.

www.architecturejournal.net - Journal 14 THE ARCHITECTURE JOURNAL

Extensin de aplicaciones empresariales

servidor y la clave primaria del registro de la base de datos del

THE ARCHITECTURE JOURNAL Journal 14 www.architecturejournal.net

Extensin de aplicaciones empresariales