Arquitectura de Infraestructura

Aprenda la disciplina,
ejerza el arte y
contribuya con sus ideas en
www.ArchitectureJournal.net
Recursos que sirven de base
Arquitectura de Infraestructura
Arquitecturas de alta
disponibilidad para
hosting masivo
Brindar informtica
integral de alta
productividad
Infraestructuras
orientadas a pruebas
Perfil del Architecture
Journal: Don Ferguson
Resolver el dilema de la
integracin
Ontologa y Taxonoma
de los Servicios en una
Arquitectura Orientada a
Servicios
Versionado en SOA
Contenidos
Prlogo
Por Simon Guest
Arquitecturas de alta disponibilidad para hosting masivo
Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael Johnson
Descubra los secretos para la creacin de infraestructuras de hosting escalables, confiables, seguras y fcil de
mantener.
Brindar informtica integral de alta productividad
Por Marc Colmes y Simon Cox
Explore una solucin tcnica para la creacin de un servicio HPC distribuido, orientado al servicio.
Infraestructuras orientadas a pruebas
19
Por Mario Cardinal
Los equipos de infraestructura tienen la oportunidad de aprender de los equipos de desarrollo el modo de
expresar las decisiones de arquitectura utilizando secuencias de comando de prueba.
Perfil del Architecture Journal: Don Ferguson
24
Don Ferguson es Asociado Tcnico de Microsoft en Plataformas y Estrategia en la dependencia del CTO.
Actualcese sobre su carrera y sus pensamientos sobre la arquitectura.
Resolver el dilema de la integracin
26
Por Jim Wilt
Aprenda una definicin del dilema de integracin y lo que puede hacer para evitarlo en su entorno.
Ontologa y Taxonoma de los Servicios en una Arquitectura

Orientada a Servicios
30
Por Shy Cohen
Los servicios se pueden obtener en diversas formas y tamaos. Vea un modo de utilizar una ontologa y
taxonoma comn para describirlos
Versionado en SOA
36
Por Boris Lublinsky
La idea de versionado de servicios es simple, pero la implementacin requiere mucha reflexin y

planificacin. Aprenda diversos enfoques para permitir esto en su organizacin.
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
Neil Hutson
Eugenio Pace
Javed Sikander
Philip Teale
Jon Tobey
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: BizTalk,
Microsoft, SharePoint, SQL Server, Visual Studio,
Windows, Windows NT y Windows Server. Cualquier
otra marca comercial es propiedad de sus
respectivos propietarios.
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.
Estimado arquitecto:
Bienvenido al Journal 11, cuyo tema es Arquitectura de Infraestructura. Hace
algunos aos, uno de mis colegas anteriores, Pat Helland, propuso una analoga
de arquitectura llamada Metrpolis. Su planteamiento era crear un paralelo
utilizando la arquitectura de construccin y planificacin de una sociedad para
dar sentido a los desafos complejos en la arquitectura de software. Una de las
cosas que siempre recuerdo de la Metrpolis es que, como arquitectos de TI, por
lo general, dedicamos proporcionalmente demasiado tiempo a nuestras propias
construcciones. Muchos de nosotros somos culpables de obsesionarnos con la
apariencia que tendr nuestra construccin y cmo se desempaar. Sin
embargo, como resultado, a veces nos olvidamos de la visin ms global. Por
ejemplo, el modo en el que nuestra construccin se adecuar a la ciudad. Para la
arquitectura de la construccin, una construccin debe ajustarse a los planos de
la ciudad en una cantidad de reas, incluidos los planos de carreteras, utilidades,
transporte, etc. Teniendo esto en cuenta para la edicin de nuestro Journal,
quera analizar los mismos desafos del modo que se relacionan con nuestra
industria.
Para encabezar esta edicin, contamos con un grupo de autores, Shaun
Hirschman, Matthew Baldwin, Tito Leverette y Michael Jonson, quienes han
escrito un artculo sobre arquitecturas de alta disponibilidad para hosting masivo.
En este artculo, el grupo comparte aspectos fundamentales para crear una
arquitectura de hosting que sea resistente y escalable. A continuacin, tenemos
a Marc Colmes y Simon Cox con una nueva visin de HPC que llaman Informtica
de Alta Productividad. Marc y Simon han trabajado juntos sobre el anlisis de las
consideraciones integrales y de infraestructura para HPC. Sigue Mario Cardinal
con un artculo llamado Infraestructuras orientadas a pruebas. Mario es un
gran defensor del Desarrollo orientado a Pruebas (TDD, sus siglas en ingls) y en
este artculo describe en lneas generales el modo en el que el TDD puede
aplicarse al nivel de la infraestructura.
Para continuar con la serie de Perfiles del Architecture Journal, para esta
edicin tuve la exclusiva oportunidad de reunirme con Don Ferguson y
preguntarle lo que significa ser arquitecto. Para quienes no lo saban, Don sola
ser Asociado de IBM y Arquitecto Principal en el Grupo de Software de IBM,
recientemente antes de unirse a Microsoft. Despus de la entrevista con Don,
contina un artculo de Jim Kilt sobre Resolver el dilema de la integracin. Jim
comparte algunos de sus desafos de integracin adems de presentarnos un
Mapeo en el pozo de la desesperacin!
Para completar esta edicin, tenemos dos artculos grandiosos sobre el tema
de la Arquitectura Orientada a Servicios (SOA) del mundo real. Comienza Shy
Cohen con una ontologa y taxonoma de servicios que puede encontrarse en
SOA, varios de los cuales se ajustan bien dentro del espacio de la
infraestructura. El ltimo artculo de esta edicin es Versionado en SOA, de
Boris Lublinsky. Boris toma un desafo que pueden enfrentar varios arquitectos
en la actualidad y analiza mltiples enfoques para el versionado de servicios.
Bien, este es todo el contenido que hemos tratado en esta edicin. Espero
que estos artculos le ayuden a considerar no slo el tipo de construcciones que
prepara para su Metrpolis, sino tambin la infraestructura que se necesita para
ayudar a las personas a que lleguen a ella.
Hasta la prxima edicin!
2005 Microsoft Corporation. Todos los derechos

reservados.
THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net
Simon Guest
Arquitecturas de alta
disponibilidad para
hosting masivo
Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael

Johnson
Sntesis
Escalabilidad y alta disponibilidad son propiedades esenciales
y a la vez opuestas para las infraestructuras de hosting. Ya
sea ingeniero de programas de cdigo abierto, consumidor
de soluciones comerciales o ingeniero TI de Microsoft, parece
que no existe la solucin milagrosa.
Al investigar diferentes aspectos de una infraestructura
de hosting, podemos encontrar tecnologas existentes que se
pueden agrupar para crear la solucin milagrosa. Este
proceso tambin ayudar a detectar las diferencias que
debemos reducir. La plataforma de la solucin milagrosa
debe ofrecer una infraestructura que permita una gran
cantidad de cuentas de clientes y debe ser escalable y con
alto grado de redundancia.
Este artculo se centrar en los componentes necesarios
para la construccin de un entorno exclusivo que sea
escalable, confiable, seguro y fcil de mantener y que al
mismo tiempo ofrezca alta disponibilidad (HA, sus siglas en
ingls). Los proveedores de aplicaciones solitarias, hasta
hosters compartidos de alta densidad, se beneficiaran de
esta solucin. Pero, Existe? De lo contrario, Cules son los
desafos que nos bloquean en la actualidad? y Cunto
podemos aproximarnos a esto?.
Historia de la industria del hosting y problemas actuales

Para comprender totalmente las complejidades de la plataforma de
Web hosting, primero debemos comprender el modo en el que se
inicio el mercado del hosting y cmo evolucion hasta su estado
actual. Antes de que el hosting tradicional comenzara a tomar forma,
los simples sitios de Web estticos eran populares y relativamente
nuevos para el pblico en general. La infraestructura que se
construy para respaldar este movimiento era igualmente bsica y se
concentr en obtener la mayor cantidad posible de clientes en vez de
brindar servicios de ltima generacin, como aplicaciones interactivas
y alta disponibilidad.
Comencemos con la descripcin de la arquitectura clsica que han
utilizado en el pasado los hosters basados en Microsoft. Un nico
servidor de Web autnomo, con servicios de FTP, que ejecuta IIS con
contenido alojado localmente en el servidor. Cada sistema autnomo
tiene un cierto costo hardware, software, licencias, redes, energa,
espacio en gabinete y dems. Algunos hosters, an han llevado esto
al extremo alojando todos los servicios en un servidor nico para una
cantidad x de clientes. Por ejemplo, tienen servidores con IIS, SQL,
software para servidor de correo de terceros y almacenamiento local
para el contenido alojado.
Estos mdulos son fciles de imaginar y de rpida implementacin,

en especial, si se venden paquetes bsicos a clientes que slo
desean alojar muy pocas pginas y nada ms complicado.
En la media que este tipo de plataforma creca, comenzaron a
surgir varios problemas: necesidad de restauracin y backup, uso de
un espacio costoso para un centro de datos, capacidad para el
servidor, clientes con alta carga y administracin general. A los
problemas de plataforma se sumaban una demanda cada vez mayor
por parte de los clientes y progresos en la nueva tecnologa de Web.
Surgieron tecnologas como PHP, Cold Fusion, ASP, JSP y ASP.NET
que ofrecan plataformas ms complejas impulsadas por el deseo de
los clientes de una funcionalidad ms rica y mejores negocios. Esto,
a su vez, produjo nuevas aplicaciones que requeran almacenes de
datos como SQL y otras tecnologas relacionadas. En la medida que
se creaban nuevas aplicaciones, el potencial comercial que ofrecan
estas aplicaciones se volvi ms evidente y ms solicitado.
Los hosters, en el intento de maximizar los resultados y simplificar
la gestin, continuaron con la gestin de todos servicios requeridos
para soportar a sus clientes sobre un servidor autnomo. Esto cre
una mayor carga en un nico servidor, obstaculizndolo y
reduciendo la cantidad de sitios Web que poda servir. La demanda
del consumidor aument de un modo ms rpido de lo que la
tecnologa de hardware poda soportar. Los hosters tuvieron que
escalar a nivel exterior, aislando y separando los servicios en varios
servidores en vez de escalar de forma vertical con un hardware ms
rpido.
EL OBJETIVO PRIMARIO AL DISEAR UNA

PLATAFORMA ALOJADA ES OPTIMIZAR LA
ESCALABILIDAD, DISPONIBILIDAD, DENSIDAD Y
PARIDAD DE PRECIOS AL MISMO TIEMPO QUE SE
SIGUE UN NIVEL DE SEGURIDAD LO MS GRANULAR
POSIBLE AISLANDO LOS CLIENTES ENTRE S.
La industria del hosting continu saturndose de compaas
competitivas en respuesta a la alta demanda de servicios en la Web
como sitios de Web dinmicos y carritos de compras para el
comercio electrnico. Este mercado prspero oblig a los hosters a
diferenciar sus servicios de los otros mediante la creacin de
acuerdos de nivel de servicio (SLAs). No slo los hosters deben
ofrecer sus servicios a un bajo costo, sino que tambin deben estar
siempre disponibles. Esto se confirma con la creciente dependencia
que poseen los clientes y negocios sobre la Web y sus demandas de
aplicaciones ms interactivas y complejas. La produccin de servicios
altamente disponibles, por lo general, da como resultado ms
servidores para soportar la redundancia as como tambin nuevos
requisitos de rendimiento, seguridad y gestin. De qu manera
pueden los hosters escalar y respaldar estos servicios con la
arquitectura de software y hardware ofrecida?
www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Debido a estos cambios en la industria, las empresas de tecnologa
de software que ofrecan la base para estos servicios se dieron cuenta
que sus actuales sistemas operativos no podan satisfacer las
necesidades del los hosters. Todava se necesitaba un alto nivel de
interaccin con el administrador del sistema para que las operaciones
siguieran ejecutndose con la menor cantidad de problemas posible.
Los ingenieros de la industria y los proveedores de servicios
independientes tomaron conciencia de la carencia que haba en los
servicios en relacin con software/hardware y emprendieron su
propio objetivo desarrollando tecnologas que cubran las carencias al
mismo tiempo que se beneficiaban.
En ese momento los hosters comenzaron a considerar la creacin
de plataformas que fueran ms escalables y que pudieran lograr una
mayor densidad. Tambin deban ser de fcil gestin. Un buen
comienzo al construir este tipo de arquitectura es analizar los varios
servicios que el hoster necesita soportar y administrar.
Consideraciones al planificar arquitecturas de alta
disponibilidad para hostings masivos
Cuando el hoster reflexiona y comienza a pensar en las tecnologas
que podra agrupar y el modo de crear una plataforma para soportar
varios servicios y sitios de Web, se le ocurren varios requisitos claves.
Estos requisitos abarcan desde la cantidad de aplicaciones o usuarios
hasta el tipo de funciones y servicios que deberan soportarse y su
impacto sobre el sistema subyacente ASP.NET, PHP, SQL y dems
y finalmente el costo por aplicacin o sitio alojado. El objetivo
primario al disear una plataforma alojada es optimizar la
escalabilidad, disponibilidad, densidad y paridad de precios al mismo
tiempo que se sigue un nivel de seguridad lo ms granular posible
aislando los clientes entre s.
Separamos estos servicios en amplios segmentos, con las
siguientes piezas principales de arquitectura: IIS clster(es), SQL
clster(es), servicios de infraestructura de soporte, como servicios
del Active Directory, System Center Operations Manager,
almacenamiento centralizado, ya sea en una red de rea de
almacenamiento o en un almacenamiento conectado a la red,
clsteres SSL de descarga, clsteres FTP, y otros clsteres similares.
La separacin de estos servicios en varios segmentos le permite al
hoster escalar la arquitectura de diferentes modos. Un hoster podra
escalar un clster de SQL de un modo diferente que un clster de
Web y presentar un conjunto diferente de problemas de arquitectura.
Otro factor que forma parte de la arquitectura es el requisito de
legado, cuyo mejor ejemplo son las Extensiones del Servidor de
FrontPage (FPSE). Miles de clientes todava las utilizan y son
necesarias si la plataforma de hosting masivo espera atraerlos. Por lo
general, estas extensiones las utilizan pequeos negocios para crear
sitios simples. Todava se utilizan para herramientas de desarrollo
como Visual Studio y Visual Web Developer por su funcionalidad de
carga para HTTP, a pesar del desaliento por parte de Microsoft. Los
componentes de legado, como FPSE, no pueden ser eliminados de un
modo simple por grandes hosts sin una prdida de la base de
clientes.
Analicemos ahora algunos de estos clsteres dentro de la
arquitectura. La pieza ms grande es el clster de Web y el segundo
es el clster de SQL. Es importante recordar que un diferenciador
clave entre lo que hacen los hosters frente a lo que hacen otras
empresas como departamentos internos de TI, es que intentarn
colocar la mayor cantidad posible de sitios o bases de datos en un
clster. Por este motivo, ciertas soluciones empresariales no
funcionan para ellos. Adems, no siempre controlan el tipo de
aplicaciones que se colocan en un servidor y por lo tanto, no pueden
definir la capacidad del mismo modo que lo pueden hacer las
empresas tpicas.
Figura 1: Modelo de distribucin de carga de la aplicacin
Firewall
Balanceador de la carga
Contenido
esttico
Contenido
dinmico
Modelos de distribucin de carga

Debido a que hay mltiples usuarios de Web, los arquitectos de hosting
deben considerar diversas opciones para distribuir la configuracin
entre todos los servidores de Web. Esta configuracin depende del tipo
de modelo de distribucin de carga que se elige. Existen varios
modelos para distribuir la carga entre los mltiples usuarios de Web.
Analizaremos dos que son comunes para las posibles situaciones de
hosting: distribucin de carga de aplicacin y distribucin de carga
conjunta.
Distribucin de carga de aplicacin
La distribucin de carga de aplicacin describe un modelo en el que la
carga se distribuye entre mltiples nodos de usuarios de Web
basndose en la funcin del servidor. Este modelo por lo general est
basado en la solicitud y utiliza las capacidades de enrutamiento de la
capa de aplicacin que varios balanceadores de carga de red soportan
en la actualidad. Este modelo permite a los hosters dividir el grupo de
servidores basndose en las cargas de trabajo del servidor. Al analizar
una implementacin tpica de este modelo, veremos que los servidores
se separan de aquellos que tratan contenido dinmico como ASP.NET o
se disea un PHP para el contenido esttico (Figura 1).
Se puede agregar an ms granularidad a esta configuracin si se
dividen ms los servidores dinmicos de acuerdo a su funcin
especfica. Esto implica la creacin de subgrupos de servidores ms
pequeos para cada tipo de aplicacin. Todo el trfico de ASP.NET sera
enrutado hacia un subgrupo de servidores de ASP.NET y todo el
contenido de PHP sera enrutado hacia otro subgrupo de servidores.
Debido a que los servidores de contenido dinmico normalmente
necesitan ms recursos, el diseo permite al hoster utilizar para esos
sitios una clase diferente de hardware del que se necesitara para el
contenido esttico.
La mayora de los hosters deben considerar el costo al disear sus
plataformas; por lo tanto, el modelo de distribucin de carga de
aplicacin tal vez no siempre sea posible simplemente porque este
modelo aumenta la cantidad de servidores requeridos. La aplicacin de
carga de distribucin tambin incrementa la complejidad al administrar
los servidores y se basa en gran medida en los equipos de conexin de
redes.

Figura 2: Escenario del grupo de aplicacin uno-a-uno
100% 90% 80% 70% -
Compartido
60% -
Uno a uno
50% 40% 30% 20% 10% 0%Aislamiento
Escala
Distribucin de carga conjunta

Para mantener un costo mnimo y tambin para lograr que la
administracin de la plataforma sea menos compleja, un hoster
puede elegir implementar un modelo de distribucin de carga
conjunta. Denominamos modelo de distribucin de carga conjunta a
aqul en el que todos los servidores comparten exactamente la
misma configuracin. Cada servidor en el centro de servidores
tambin es capaz de servir tanto el contenido esttico como el
dinmico. En los sistemas que ejecutan IIS, el diseo del grupo de
aplicaciones es indispensable para maximizar la escala en este tipo de
modelo.
Ajustar Microsoft IIS para el hosting masivo
Dentro de una compaa de hosting masivo que se centra en la
plataforma de Microsoft, existe una constante presin de un nivel ms
alto de densidad sobre cada servidor del grupo. Con una arquitectura
alta disponibilidad compleja, el hoster aumenta su modelo de
densidad; sin embargo, an aparecen obstculos en el desempeo,
en particular, con los grupos de aplicaciones.
En IIS, el diseo del grupo de aplicaciones es fundamental para
lograr la mxima densidad. Si no se dedica tiempo a planificar de un
modo apropiado el diseo del grupo de aplicaciones, esto puede
causar problemas inesperados de estabilidad y rendimiento. Los
grupos de aplicaciones tratan verdaderamente el aislamiento y existe
una correlacin directa entre el nivel de aislamiento que se elige y la
cantidad de aplicaciones que se colocan en el servidor. Al disear
grupos de aplicaciones se debe comparar la necesidad de seguridad
con la estabilidad deseada. Los hosters deben elegir entre dos
escenarios de grupos de aplicaciones, un escenario de grupo de
aplicaciones compartidas uno-a-muchos o un escenario uno-a-uno. Es
importante observar que en la Figura 2, el escenario del grupo de
aplicaciones uno-a-uno muestra una tendencia ms hacia el
aislamiento pero lejos de la escala. Por otro lado, el escenario del
grupo de aplicaciones compartidas, muestra una tendencia hacia
niveles superiores de la escala mientras que se aleja del aislamiento.
En el mejor de los casos, el hoster elegira una solucin que le
permitiera maximizar la escala sin sacrificar el aislamiento y la
seguridad.
Anlisis de tendencias: Aislamiento vs. Escala
El escenario de aislamiento uno-a-uno se define con un grupo
de aplicaciones asignado a una aplicacin nica o en un escenario de

hosting de Web compartido para un sitio de Web nico. Esto permite
que un hoster logre un alto nivel de aislamiento ya que cada aplicacin
o sitio de Web se ejecuta dentro de un proceso nico y no comparte
recursos con otros en el servidor. sta es una solucin ptima para un
proveedor de software independiente o hoster que debe asegurar a sus
clientes que otros en el mismo servidor no tendrn acceso a sus datos
importantes. Sin embargo, este escenario es limitado en un escenario
de hosting masivo. Si bien brinda el nivel deseado de aislamiento y
seguridad debido a los requisitos de memoria, no cumple el objetivo de
proporcionar a los hosters la escala que desean. Ya que cada grupo de
aplicaciones ejecuta la memoria de sus consumidores y finalmente se
produce un embotellamiento.
La incorporacin de cdigo dinmico dentro de la plataforma aade
un nuevo nivel de complejidad. Por ejemplo, las aplicaciones ASP.NET
aumentan la cantidad de memoria necesaria para el grupo de
aplicaciones. Esto se vuelve un problema para el hoster porque limita
la cantidad de sitios de Web dinmicos que pueden ejecutarse en un
servidor. Comienzan a observar que pueden escalar dentro de cientos
de sitios en vez de miles de sitios, que es el punto de referencia para la
mayora de los progresos en la tecnologa del hardware.
Concretamente, la incorporacin de la arquitectura de 64-bits le ha
permitido a varios hosters darse el lujo de agregar enormes cantidades
de memoria a sus servidores. Si bien esto les permite ir ms all de
obstculos potenciales, tambin se pueden descubrir otros problemas.
Escenario del grupo de aplicaciones compartidas
Un escenario del grupo de aplicaciones compartidas describe una
situacin en la que ms de una aplicacin o sitio de Web reside en el
mismo grupo de aplicaciones. Existen dos configuraciones diferentes
para grupos de aplicaciones compartidas. La primera es uno-para-N en
la que el proveedor de hosting dedica un nico grupo de aplicaciones a
una cantidad predefinida de sitios de Web. La segunda es una
configuracin uno-para-todos en la que el host coloca todos los sitios
de Web en un nico grupo de aplicaciones. Un escenario del grupo de
aplicaciones compartidas permite escalar mejor ya que no somete al
sistema a las limitaciones de la memoria impuestas por un diseo de
grupo de aplicaciones uno-a-uno.

Existe una preocupacin y es que las aplicaciones y sitios de Web
en un grupo de aplicaciones compartidas podran potencialmente dar
a algunos usuarios acceso a los datos de otros. Se deben realizar
ciertas migraciones para garantizar que estas aplicaciones y sitios de
Web estn asegurados. Por ejemplo, es necesario que cada sitio de
Web tenga un usuario annimo nico y se debe aplicar una lista de
control de acceso a los archivos de la Web. Tambin, las aplicaciones
ASP.Net se deben configurar con seguridad de acceso al cdigo y se
deben ajustar a un nivel medio de confianza. Estos pasos ayudarn a
garantizar que las aplicaciones y los sitios de Web en el servidor sean
seguros, an en un grupo de aplicaciones compartidas.
Debido a que todas las aplicaciones se ejecutan bajo el mismo
proceso de grupo de aplicaciones compartidas es que carecen del
aislamiento que varios proveedores de hosting necesitan. Esto puede
ser una preocupacin en escenarios de alta disponibilidad ya que un
problema afecta a todos los otros sitios de Web y aplicaciones del
mismo grupo. Por ejemplo, una aplicacin podra causar que un grupo
de aplicaciones se reinicie o an peor, que se cierre completamente.
Tambin es ms difcil para los administradores del sistema identificar
un problema cuando hay varios sitios y aplicaciones en un nico
grupo. Si bien hay herramientas disponibles que permiten al host
aislar los problemas dentro del grupo de aplicaciones, esta tarea se
logra con mayor facilidad cuando se utiliza un grupo de aplicaciones
uno-a-uno para modelar un sitio de Web.
placa. Las secciones que se detallan a continuacin dividen las

diferentes arquitecturas de almacenamiento que son comunes entre las
compaas de hosting.
Almacenamiento directamente conectado (DAS)
DAS es uno de los mtodos de almacenamiento ms comunes y
clsicos que utilizan las compaas de hosting de Web. Se trata de
servidores de Web autnomos en los que el contenido se ubica de
forma local. El beneficio principal es que si un nico servidor autnomo
deja de funcionar, toda la base del cliente no queda sin conexin. La
desventaja es que los clientes estn sujetos a cualquier tipo de falla del
hardware, no simplemente a una falla del subsistema del disco.
Adems, este tipo de configuracin presenta problemas como lmites
de densidad, problemas de migracin y falta de alta disponibilidad para
los sitios de Web y distribucin de la carga.
LA INCORPORACIN DE LA ARQUITECTURA DE 64BITS LE HA PERMITIDO A VARIOS HOSTERS DARSE EL

LUJO DE AGREGAR ENORMES CANTIDADES DE
MEMORIA A SUS SERVIDORES. SI BIEN ESTO LES
PERMITE IR MS ALL DE OBSTCULOS POTENCIALES,
TAMBIN SE PUEDEN DESCUBRIR OTROS PROBLEMAS.
Planificacin de un grupo de aplicaciones con alta

disponibilidad
El desafo de los hoster es lograr un equilibrio entre lograr altos
niveles de aislamiento y maximizar la escala. Debido a esto, varios de
ellos se ven obligados a utilizar el escenario de grupo de aplicaciones
hbridas que mencionamos anteriormente. Un escenario tpico incluira
mltiples grupos de aplicaciones, cada uno de los cuales cumple un
propsito especfico. Por ejemplo, los sitios de Web que slo poseen
contenido esttico, podran colocarse todos en un nico grupo de
aplicaciones compartidas. Esto es posible ya que el contenido esttico
no est asociado con los problemas de rendimiento y seguridad que
surgen con el contenido dinmico. Todos los otros grupos de
aplicaciones estaran dedicados a sitios que tengan contenido
dinmico. Esto permite que el hoster asigne mayores recursos para
estos sitios. Esta configuracin es ms frecuente en entornos de
hosting compartido en los que una nica plataforma debe brindar
servicio a clientes que poseen tanto contenido esttico como
dinmico.
Almacenamiento conectado a la red (NAS)

La mayora de los host que han elegido plataformas altamente
escalables han optado por utilizar NAS como el almacenamiento remoto
centralizado para todos sus clientes. En entornos de Windows
altamente disponibles, NAS se accede mediante el Sistema Comn de
Archivos de Internet (CISS), generalmente entre una red de
almacenamiento dedicado. El contenido de Web de los clientes se
almacena centralmente en el NAS con la ruta hacia el NAS almacenada
como ruta lgica utilizando un sistema de archivos distribuido (DFS).
La combinacin de NAS y DFS permite que un hoster basado en
Windows distribuya los clientes entre mltiples subsistemas de
almacenamiento NAS, impidiendo que un problema global, afecte a
esos clientes.
Optimizar CISS, TCP/IP y el NAS contribuye en gran medida
respecto de lo escalable que es el NAS con la cantidad de sitios de
clientes simultneos para los cuales puede estar sirviendo contenido. Si
el NAS posee una escasa optimizacin, los hosts pueden presentar
problemas que pueden afectar toda la base del cliente. Sin embargo,
los hosts mitigan esto utilizando mltiples subsistemas de NAS para
Duplicacin de la configuracin
Otro requisito fundamental para el hosting masivo en entornos de alta diferentes segmentos de clientes y dedicando interfaces y redes de
almacenamiento para este tipo de trfico.
disponibilidad, es mantener el estado y la configuracin entre todos
Varios subsistemas de NAS poseen capacidades de duplicacin y
los usuarios de Web del grupo. Si bien hay otras configuraciones que
deben existir en cada usuario, la ms importante es la del servidor de captura de imagen. Los hosters utilizan estas tecnologas para ofrecer
un proceso consistente para la recuperacin y emergencias en
Web. Algunos servidores de Web poseen soporte para un almacn de
especial, si se considera que el sistema de almacenamiento podra
configuracin centralizada. Para quienes no lo poseen, se debe
contener cientos de miles de clientes.
implementar alguna solucin de software para duplicar la
Un problema con el subsistema de almacenamiento NAS puro es que
configuracin entre los servidores.
debido a que tecnologas como SQL no admiten el almacenamiento
remoto de sus bases de datos entre los CISS, esto limita al hoster
Almacenamiento del contenido
respecto del tipo de servicio que puede ofrecer.
Uno de los principios centrales para las plataformas de hosting
masivo, altamente escalables que enfrentan los arquitectos es
Red de rea de almacenamiento (SAN)
determinar la ubicacin del contenido del cliente que ser
Varios sistemas de almacenamiento de las empresas pueden operar
almacenado. En la mayora de los casos, se trata contenido que est
tanto una SAN como un NAS, con una diferencia clave que es el
dentro de SQL o en el disco. Ya que el punto de inicio de la
mtodo que se utiliza para conectarlos. En el caso de una SAN, los
arquitectura es un clster configurado con miles de sitios, no es
mtodos ms importantes son el Canal de Fibra (FC) y iSCSI.
prctico ubicar el contenido en discos directamente conectados a la

Las compaas de hosting pueden construir sistemas de correo y
SQL escalables de alta disponibilidad, como por ejemplo Exchange, si
utilizan las capacidades de una SAN como el almacenamiento
centralizado para estos tipos de clsteres. Adems, cuanto ms
avanzada es la SAN, ms opciones tiene la compaa de hosting para
realizar tareas como gestin de recuperacin y captura de imgenes
dentro del SQL o Exchange.
Uno de los principales inconvenientes para un sistema de
almacenamiento empresarial es el costo en el que incurre el hoster.
Los hosters son cuidadosos al asegurar que el producto que van a
implementar tenga un rendimiento de la inversin (ROI) lo
suficientemente alto como para justificar el costo de un SAN.
NO EXISTE UN MODO RENTABLE DE CONSTRUIR UNA

PLATAFORMA DE CLSTER DE SQL COMPACTA, DE
ALTA DISPONIBILIDAD Y ESCALABLE. CADA
TOPOLOGA DEL CLSTER TIENE SUS DESVENTAJAS
JUNTO CON EL HECHO DE QUE LOS HOSTS NO TIENEN
CONTROL SOBRE EL DISEO DE LA APLICACIN DE
LOS CLIENTES.
Clster de SQL
SQL es un servicio importante que ofrecen varios hosters a la mayora
de sus clientes. Sin embargo, es una de las reas claves que muchos
hosts no implementan como un clster. Existen varias razones para
esto y la ms importante es el costo y la licencia. No obstante, los
hosts que eligen un cluster de SQL altamente disponible deben
disear su arquitectura de modo que seleccionen el tipo correcto de
metodologa de clster que soporte diversas bases de datos.
A diferencia de otras empresas en las que el clster de SQL est
compuesto de una cantidad relativamente pequea de bases de
datos, las compaas de hosting implementarn cientos, sino miles,
de bases de datos para un nico clster de base de datos. Este
clster debe ser resistente tanto en rendimiento como en tiempo de
actividad. Debido a que las compaas de hosting no tienen control
sobre la forma en la que sus clientes escriben sus aplicaciones, se
presentan algunos problemas nicos al disear un clster para un
hosting masivo. En un entorno de hosting, cada cliente posee 1-n
bases de datos asignadas a l. Estas bases de datos pueden
almacenarse en un nico clster o distribuirse entre mltiples
clsteres. El clster ms comn que un hoster construira para un
hosting SQL masivo es el clster de SQL activo-pasivo estndar. Sin
embargo, en la medida que los hosts entran en un hosting de
software como servicio (SaaS), los requisitos del clster de SQL se
convierten de redundancia del nodo a redundancia de datos. Esto
agrega ms problemas ya que estos mismos sistemas an alojarn
numerosas bases de datos.
No existe un modo rentable de construir una plataforma de clster
de SQL compacta, de alta disponibilidad y escalable. Cada topologa
del clster tiene sus desventajas junto con el hecho de que los hosts
no tienen control sobre el diseo de la aplicacin de los clientes. El
clster de SQL ideal permitira a los hosts realizar una distribucin de
carga, adems de duplicar la base de datos, sin tener que ocuparse
de los problemas de colisin de datos mientras mantienen una gran
cantidad de bases de datos entre los clsteres.
Conclusin
Los proveedores de servicios deben enfrentar continuamente desafos
para cumplir con la creciente demanda de los clientes de nuevos
servicios que ofrecen mayor valor para las pequeas y medianas
empresas, desarrolladores, consumidores y diseadores.
Deben brindar un alto grado de servicio para mantener la lealtad del

cliente y lograr sus objetivos comerciales. Los proveedores de servicios
buscan la forma de producir la plataforma de Web milagrosa que
ayude a reducir el costo total de propiedad (TCO) y brindar a sus
clientes una respuesta de forma efectiva y eficaz.
Cuando hacemos referencia a una solucin de plataforma de Web
compuesta de servicios de Web, almacenamiento de datos y
almacenamiento de bases de datos, inevitablemente ocurre un
problema dentro de alguno de estos componentes. Una solucin es tan
slida como su punto ms dbil. Fundamentalmente, cada componente
de una solucin debe ser escalable a nivel exterior y de forma
ascendente y tambin debe ser rentable.
Este artculo no trata las tecnologas (cdigo abierto o cdigo
cerrado) que pueden cumplir el objetivo o lo han cumplido en algunas
reas, sino que trata los problemas bsicos de arquitectura que no se
tienen en cuenta como primordiales cuando se desarrollan
tecnologas. En la actualidad, no es suficiente crear tecnologa porque
s con el objeto de ocupar una posicin. Slo mediante la estrategia,
planificacin y desarrollo de soluciones de gran escala podremos
respaldar requisitos de gran escala. El mundo est creciendo, las
necesidades son cada vez mayores y slo tiene sentido que las
infraestructuras tambin.
Sobre los autores

Shaun Hirschman ha trabajado en el rea del hosting por casi ocho
aos y est muy en sintona con los desafos de la tecnologa y los
negocios inherentes. Antes de unirse a Microsoft en el 2006, Shaun
comenz en la industria del hosting como soporte tcnico y ascendi a
la posicin de administrador senior de sistemas Windows. Posee un
gran conocimiento tcnico y experiencia en los sistemas basados en
Microsoft. En su mayora, le gusta experimentar con tecnologas de
hardware y software de ltima generacin para apaciguar su deseo por
aprender.
Mathew Baldwin ha trabajado en el rea de servicios alojados en los
ltimos diez aos. En el pasado, ha cumplido funciones como
arquitecto, ingeniero de sistemas senior, solucionador de problemas
regular y consultor para plataformas basadas en Microsoft con
mltiples compaas de servicios alojados. Contribuy positivamente
para lanzar al mercado la primera plataforma de hosting compartida,
agrupada de alta disponibilidad Windows 2003 y trabaj estrechamente
con Microsoft en varias iniciativas. En la actualidad trabaja como
arquitecto senior para Affinity Internet.
Tito Leverette ha trabajado en el rea de hosting por ms de ocho
aos. Comenz su carrera con Interland Inc, actualmente Web.com.
Antes de unirse a Microsoft, Tito fue arquitecto en el equipo de
plataforma de Web de SunTrust Inc., el noveno banco ms grande de
los Estados Unidos de Amrica. Tito posee aos de experiencia en el
diseo, creacin e implementacin de infraestructuras de Web para
grandes empresas as como tambin para clientes de hosting. Es
graduado del Instituto de Tecnologa de Georgia (Georgia Tech).
Michael Johnson dedic ms de siete aos como empleado en el rea
de proveedor de servicios de Web donde desarroll y dise soluciones
y aplicaciones altamente escalables sobre productos de Microsoft. En la
actualidad trabaja como arquitecto experto de Web para Microsoft.
Brindar informtica
integral de alta
productividad
Por Marc Holmes y Simon Cox
Sntesis
En la actualidad, realizar un clculo informtico complejo
cientfico y de ingeniera significa mucho ms que
simplemente comprar una gran supercomputadora. Si bien
tradicionalmente HPC significa High Performance
Computing (Informtica de Alto Rendimiento), creemos que
la solucin integral real debera ser Informtica de Alta
Productividad. A lo que queremos referirnos con
Informtica de Alta Productividad es a toda la estructura de
manipulacin de datos e informtica y tambin a las
herramientas, tecnologas y plataformas necesarias para
coordinar, procesar y monitorear este clculo integral.
Muchos desafos estn asociados con la produccin de una
solucin general de Informtica de Alta Productividad (HPC)
para problemas de dominio cientficos y de ingeniera. En
este artculo tratamos estos desafos basados en los
requisitos tpicos de estos problemas, proponemos varias
soluciones y demostramos el modo en el que han sido
implementados para usuarios a travs de un modelo
cientfico especfico del entorno, siguiendo el proceso desde
el comienzo hasta el final. Nuestra solucin tcnica general
se podr poner en prctica para cualquier solucin que
requiera capas de interfaz y control para un servicio de HPC
orientado al servicio distribuido.
La solucin tiene en cuenta la cadena de valor total para las
soluciones de HPC y utiliza la tecnologa de Microsoft para superar
esta cadena de valor ms all de simples mejoras del rendimiento en
el hardware, software y algoritmos que, como se describe, no
siempre es una opcin posible. La clave de nuestra solucin es la
capacidad de integrarse con otros sistemas mediante estndares
abiertos.
Requisitos para soluciones de informtica de alta
productividad
En los dominios de ingeniera y ciencia, las soluciones HPC pueden
utilizarse para resolver problemas matemticos complejos en una
diversidad de reas, como clculos estadsticos para epidemiologa
gentica, clculos de dinmica de fluidos para la industria
aeroespacial y modelado del medio ambiente global. Cada vez ms, el
desafo est en integrar todos los componentes requeridos para
componer, procesar y analizar los resultados de problemas de
manipulacin de datos e informtica de gran escala.
An con diferencias tan diversas en los problemas, los requisitos
para las soluciones poseen las mismas caractersticas debido al
contexto del dominio y la complejidad del problema en cuestin.
Diseada para una solucin a un problema especfico

Debido a que las interacciones de la industria y los clculos son
diversos, no hay proveedores de soluciones particulares para un
problema determinado, lo que da como resultado soluciones
altamente individualizadas que surgen de empresas o
departamentos de investigaciones que necesitan estos clculos. Esta
individualidad se compone de una pequea cantidad de equipos que
realmente buscan resolver estos problemas y tal vez necesitan
mantener la propiedad intelectual de los algoritmos u otros aspectos
de procesos especficos. La individualidad en s misma no es un
problema puede ser algo muy bueno pero debido a que las
soluciones tcnicas son medios para lograr un objetivo, es probable
que estas soluciones individuales no sean productizadas y por lo
tanto, probablemente sean difciles de relacionar y poco claras.
Procesos y clculos de larga ejecucin
El avance tecnolgico de la infraestructura requerida para realizar
procesamientos a gran escala y administrar cantidades masivas de
datos ha brindado oportunidades para desempear procesos que
anteriormente eran poco prcticos desde el punto de vista de la
informtica. El desarrollo de nuevos algoritmos y la paralelizacin del
cdigo para que se ejecuten de modo simultneo sobre varios
clsteres informticos pueden tener un efecto radical, reduciendo el
tiempo de procesamiento en diversos rdenes de magnitud. Por lo
tanto, un procesamiento interminable, tal vez, podra ejecutarse en
varias semanas o meses. Este xito ha permitido a las industrias
lograr importantes resultados y aprovechar estas posibilidades para
ofrecer ms orientacin a los desarrollos.
Requisitos para la informacin documentada
En reas de investigacin, existe una necesidad muy importante de
registrar la informacin por varios motivos. Puede simplemente
existir la necesidad de volver a ejecutar algoritmos para asegurar
que se produzcan los mismos grupos de resultados como un ejercicio
de tranquilidad, pero muy probablemente, esto ser requerido
como parte de prueba y de backup cientfico para publicar una
investigacin. Pueden tambin existir razones estatutarias para esta
informacin documentada: en la industria aeroespacial, en el caso de
una investigacin de accidente areo, los ingenieros que toman
decisiones determinadas de ingeniera pueden ser responsables de la
causa del accidente y estar sometidos a procesos penales. Por lo
tanto, la necesidad de recrear estados especficos y grupos de
resultados segn sea necesario y de seguir los pasos de decisin
hacia estas elecciones es de extrema importancia. La complejidad de
estas tareas es an mayor cuando uno considera que el ciclo de vida
del diseo de un avin podra ser de 50 aos.
Volmenes significativos de datos y movimiento de datos
Deep Thought desempe una de las tareas ms grandes de HPC en
Informtica de alta productividad

los ltimos tiempos (de ficcin). Dada una pregunta simple (Cul es
la respuesta a la vida, el universo y todo lo dems?), arroj una
respuesta simple (42), aunque, despus de varios millones de aos
de procesamiento y una pequea pausa desconcertadora al final del
proceso.
Figura 1: Los esfuerzos para mejorar la velocidad del procesamiento

se agrupan en tres zonas interrelacionadas, formando un ciclo.
Para mejorar la velocidad de los procesamientos, un equipo de

desarrollo debe:
Utilizar ms o mejor hardware. Los beneficios de los procesadores
Hardware
Algoritmos
Existe, por supuesto, un modo simple de mejorar el valor de una

solucin de HPC: Hacerla ms rpido. Sin embargo, para problemas de
suficiente complejidad informtica, en cierto punto, pasa a ser poco
provechoso continuar el intento de mejorar la solucin debido a las
limitaciones de la tecnologa. Los esfuerzos para intentar mejorar la
velocidad de los procesamientos se pueden representar mediante el
ciclo que se muestra en el Figura 1.
Software
Sin embargo, la realidad es que es muy probable que los clculos

significativos que requieren una gran cantidad de procesamiento
impliquen importantes cantidades de datos a lo largo de todo el ciclo
de vida del clculo. An, con la simplicidad del ingreso de datos y el
resultado del estilo de Deep Thought, los grupos de datos operativos
dentro del espacio de problema durante el clculo, pueden ser
significativos. Se deben desarrollar estrategias para administrar estos
datos y sus metadatos. Dada la necesidad de la informacin
documentada, estas estrategias deben ser flexibles y eficaces, y
deben estar integradas dentro procesos de flujo de trabajo utilizados
para coordinar los clculos.
Mejorar el valor de las soluciones de informtica de alta
productividad
Debido a la complejidad de los problemas de dominio y los requisitos
descriptos anteriormente, la conclusin final es que las soluciones
generalmente se disean para obtener resultados. Esto, es en cierto
modo un logro y, en primer lugar, deja de lado el esfuerzo intelectual
que implica el desarrollo de algoritmos informticos y soluciones
conceptuales.
ms rpidos, discos ms rpidos, mayor memoria, etc., podran estar

limitados por la capacidad del software o los algoritmos para utilizar
el hardware disponible. Tambin, est limitado por los ciclos de
lanzamiento de hardware de nueva generacin y probablemente est
muy limitado por el presupuesto.
Utilizar ms o mejor software. Es ms probable que los algoritmos en
s mismos sean un problema que el software subyacente, pero a
veces, pueden existir mejoras en la manipulacin de datos u otras
funciones para proporcionar un avance til. Esto tambin puede estar
afectado por restricciones presupuestarias.
Utilizar mejores algoritmos. Mejores algoritmos requieren invencin
que simplemente puede no ser posible y es probablemente menos
predecible que las mejoras de software o hardware, aunque cuando
ocurre puede brindar la mejora ms importante de todas.
Por lo tanto, el desafo ante mejoras continuas de plataforma sobre un
nivel bsico es fcil de comprender pero difcil de lograr. Como
resultado, los equipos que utilizan soluciones de HPC tienden a ser
pragmticos respecto de la cantidad de tiempo que les lleva completar
los clculos ya que comprenden que estn aprovechando al mximo las
tecnologas disponibles y, como mencionamos anteriormente, pueden
sentirse satisfechos por al menos haber completado la operacin.
Una vez que se han reducido los tiempos informticos hasta ser lo
ms prcticos posible, entonces, mejorar el valor de estas soluciones
es cuestin de considerar el proceso total y las repercusiones de
realizar clculos para reducir an ms el tiempo total en nuevas
comprensiones cientficas o de la industria. Dada la naturaleza de la
investigacin/ingeniera de los problemas, entonces el proceso total
generalmente implica un flujo de trabajo humano antes o despus de la
tarea informtica. Tambin se trata del desarrollo de un grupo de
Figura 2: Escenario de informtica general
Escenario de informtica
Acceso
Usuario
Solicitud
Proceso
Anlisis
Inicio de sesin
Carga
Preproceso
Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
Aprobacin
Postproceso
Descarga

soluciones para proporcionar interfaces y controles que posibiliten
una ejecucin eficaz del proceso total, permitiendo a los
investigadores e ingenieros realizar sus tareas de un modo ms
rpido y eficaz.
Definir el problema y la solucin
Utilizar la cartera disponible de tecnologas de Microsoft nos permite
crear una arquitectura ms completa para una solucin de HPC y
posibilita la realizacin de funciones que brindan valor adicional a los
equipos que utilizan la solucin. Adems, el uso de estas tecnologas
puede construir de un modo integrado e interactuar con las
infraestructuras existentes. Esta seccin del artculo describe una
arquitectura posible y algunas caractersticas de esta arquitectura as

como tambin el valor que proporcionan.
Escenarios del problema
Es difcil generalizar completamente una solucin de HPC debido a las
necesidades especficas de un dominio individual y a los procesos
comerciales que surgen como parte de los desafos de ingeniera que se
presentan normalmente. Sin embargo, podramos considerar tres
situaciones posibles para la solucin. La primera es la situacin bsica
del usuario: finalizar una tarea de informtica. Las otras dos
situaciones posibles son administracin y creacin y soporte para este
proceso.
Ciencia ambiental de alta productividad integral

El proyecto de modelo del sistema Grid-ENabled Integrated Earth
(GENIE) proporciona una estructura accesible por red que facilita la
integracin, ejecucin y administracin de los modelos componentes
para el estudio del sistema terrestre sobre escalas de tiempo
milenarias. Los simulacros basados en la estructura GENIE deben
seguir procedimientos de operaciones complicados entre diferentes
modelos y recursos informticos heterogneos.
El proyecto GENIE ha desarrollado una estructura para la
composicin, ejecucin y administracin de modelos integrados del
sistema terrestre. Los cdigos componentes (ocano, atmsfera,
superficie terrestre, hielo marino, capas de hielo, biogeoqumica, y
dems) de complejidad y resolucin variada pueden unirse de un
modo flexible para formar una serie de modelos del clima, eficaces,
que sean capaces de simular sobre escalas de tiempo milenarias. El
proyecto rene un grupo distribuido de cientficos del medio ambiente
con un inters en comn por el desarrollo y uso de los modelos GENIE
para comprender el sistema terrestre. Los simulacros del sistema

terrestre comprenden muchos datos as como tambin mucha
informtica. La estructura GENIE se ha diseado para soportar la
ejecucin de estos simulacros entre mltiples recursos informticos y
datos distribuidos por un perodo de tiempo extenso. Aprovechamos la
variedad de recursos heterogneos, incluyendo la Red Nacional del
Reino Unido de recursos informticos en paralelo (que ejecuta Linux y
Windows Compute Cluster Server) y el aprovechamiento de los ciclos
de escritorio en sitios distribuidos. Nuestro almacn de datos de
infraestructura informtica utiliza Oracle 10G para almacenar
metadatos sobre nuestros simulacros y el servidor SQL para coordinar
el seguimiento de persistencia de nuestros flujos de trabajo en
ejecucin. (Ver Figura 1)
En Supercomputing 2006, en Tampa, Fla., mostramos el modo en el

que la aplicacin de la metodologa de flujo de trabajo descripta en el
articulo puede proporcionar los
simulacros de GENIE con un entorno de
Figura 1: La Ciencia Ambiental de alta productividad integral soporta: (a) Interfaz de Web para
rpida composicin de simulacros y un
clientes utilizando Windows Presentation Foundation, (b) Windows Workflow Foundation para crear y entorno de hosting eficaz para coordinar
coordinar simulacros y (c) Infraestructura heterognea compuesta de Recursos Informticos de
su ejecucin. Los cientficos que
Windows y Linux y almacenamiento de datos de Oracle y SQL Server.
participan en la colaboracin, estn
investigando el modo en el que la
Base de
circulacin termosalina en el Atlntico
datos
Tiempo de ejecucin del
la densidad del agua marina es
NGS
persistente
flujo
de
trabajo
DB
controlada por la temperatura (termo) y
Flujo
de
trabajo
Servicios
Oracle
la salinidad (salina) y las diferencias de
MS
http(s)
Configuracin del
10g
SQL
densidad impulsan la circulacin
experimento
Recopilacin
Servicio de
DB
ocenica responde a los cambios de
de secuencias
IE
7
Web
Recurso
de comandos Procesamiento
niveles de dixido de carbono en la
Almacenamiento de archivos Geodise
Cliente
del
Cliente de
MS MQ
atmsfera e intenta comprender, en
explorador
programacin
Infraestructura heterognea
particular, las estabilidad de las
Control
Trabajo
cientfica
Servicio de
Eventos
corrientes ocenicas ms importantes
Servicio de Red
(Matlab, Python, ...)
Web
de
Windows
y
API/CMD
Post
Nacional
bajo distintos contextos de cambios
Windows
Presentation
Procesamiento
Servicio de
llamadas
Microsoft CCS
climticos.
Foundation
WS Communication
Web
Grupo Condor
Globus
Clster de Linux
SSH
Recursos informticos
Interfaces
Foundation
Clientes
alternativos
Microsoft Institute of High Performance

Computing: Matthew J. Fairman, Andrew
R. Price, Gang Xue, Marc Molinari, Denis
A. Nicole, Kenji Takeda, and Simon J.
Cox
Colaboradores externos:: Tim Lenton
(Facultad de Ciencias Ambientales,
Universidad de East Anglia) y Robert
Marsh (Centro Nacional de Oceanografa,
Universidad de Southampton)
Simulacro
Flujo de trabajo
Interfaz de Web del cliente
Figura 4: Escenario de administracin general
Figura 3: Escenario de autora general

Escenario de autora
Escenario de administracin
Desarrollar
Publicar
Actividades
Catlogo
Algoritmos
Configuracin
Administrar
Monitoreo
Autor
Usuario
avanzado
Flujos de trabajo
Administrador
Produccin
Escenario de informtica. El proceso informtico se divide en

cuatro pasos fundamentales para un usuario tpico que aseguran la
finalizacin de la tarea: acceso, solicitud, proceso y anlisis. (Ver
Figura 2)
Acceso:
Inicio de sesin: El usuario debe poder iniciar la sesin de la
solucin y deber identificarse como usuario vlido. Es posible que

entonces puedan ver slo la informacin relevante a su funcin y/o
grupo.
Inicializacin: Antes de realizar una solicitud del trabajo, puede
existir la necesidad de configurar un panel de control para ejecutar
la tarea. Dada la naturaleza de la informtica de larga ejecucin,
una ejecucin del proceso puede considerarse un proyecto.
Solicitud:
Carga: Un usuario debe poder cargar o acceder a grupos de datos
que estn previstos para ser utilizados como parte de un trabajo.

Los grupos de datos pueden ser grandes, no homogneos o de
origen externo, por lo tanto, se necesita un paso especfico en el
flujo de trabajo para obtener estos datos y dividirlos entre el nodo
del clster de manera que equilibre la cantidad prevista de trabajo.
Insercin de datos: un usuario debe poder aadir parmetros y
metadatos asociados para garantizar que el trabajo se ejecute
exitosamente. Estos parmetros se capturan para reutilizacin y
auditora.
Aprobacin: despus de aadir parmetros y cualquier otra
informacin requerida, es probable que se pida aprobacin antes
de presentar el trabajo. Entonces, probablemente se producir
algn tipo de flujo de trabajo de aprobacin, seguido de una
presentacin del trabajo del usuario.
Proceso
Preproceso: El paso de preproceso para un trabajo puede realizar
diversas cosas. Probablemente traslade los grupos de datos a los

nodos del clster y tal vez realice un grupo de procesamientos
iniciales, como la generacin de medidas analticas para ser
utilizadas en el procesamiento principal. Tambin puede inicializar
estructuras de datos y evaluar todos los datos para su validacin
antes de ejecutarlos.
Proceso: Esta fase representa el procesamiento paralelo en s.
Cada nodo ejecutar una porcin y puede ser necesario pasar
resultados intermedios a otros nodos para que se complete el
proceso total (trabajo de paso de mensajes). Otra opcin es que
10
Cuenta
los datos pueden ser propicios para ser computados dentro de

porciones totalmente aisladas, como situaciones que pasara si o
un anlisis paramtrico. Esta fase puede ocurrir durante un tiempo
potencialmente significativo. Lo ideal sera que se proporcione
algn comentario al usuario final durante este tiempo.
Post-proceso: El paso final en el procesamiento en s es similar al del
preprocesamiento en el sentido de que es posible que se complete
algn trabajo con los datos obtenidos. Esto puede comprender
movimientos de datos hacia almacenes, agregacin de datos de
nodos separados, operaciones de depurado, tareas de visualizacin,
etc.
Anlisis:
Automtico: Si bien es probable que los resultados de la tarea
necesiten intervencin especializada para comprenderlos

verdaderamente, es posible realizar un anlisis automtico, en
particular, en el caso de un anlisis estadstico en el que los patrones
son importantes y fciles de automatizar.
Con conexin: El usuario debe poder realizar un anlisis bsico sin
tener que solicitar todo el grupo de datos. Esto puede presentarse
como herramientas con paradigmas de inteligencia comercial
segmentacin y separacin, etc.
Descarga: Por ltimo, el usuario debe poder recuperar los grupos de
resultados para la manipulacin avanzada sin conexin, segn sea
necesario.
Escenario de autora: El escenario de autora trata los aspectos del
proceso total para proporcionar capacidades para que un usuario final
complete un trabajo de clculos. En trminos generales, el autor de un
proceso debe poder desarrollar nuevas capacidades y procesos y
publicarlos para el consumo de los usuarios finales. La Figura 3
muestra el escenario de autora para dos participantes: autores y
usuarios avanzados. La diferencia entre estas funciones es que un
autor probablemente desarrolle cdigo, mientras que un usuario
avanzado posiblemente configure el cdigo existente. El escenario de
autora puede describirse de la siguiente manera:
Desarrollo:
Actividades: Un desarrollador puede querer construir actividades o
elementos del proceso diferenciados que puedan utilizarse como

parte del proceso total de una tarea de informtica. Un ejemplo
podra ser una actividad genrica para llevar a cabo un FTP del
conjunto de resultados.
Algoritmos: El desarrollador puede crear los algoritmos reales para
que se utilicen en el paso de clculos del proceso del usuario final.

Flujo de trabajo: Un desarrollador de usuarios avanzados puede
definir flujos de trabajo de clculos especficos mediante la unin

de actividades y algoritmos para crear un paso de cmputos total
compuesto de pre y post procesamientos as como tambin de la
tarea de cmputos en s.
Publicacin:
Catlogo: Despus del desarrollo de actividades, algoritmos y
flujos de trabajo, el autor desear realizar un catlogo del

desarrollo para que lo utilicen otros autores o usuarios finales.
Configuracin: Es posible que se requiera la configuracin de
algunas actividades o flujos de trabajo, como restriccin de acceso
u otras normas que regulen el uso de la tarea desarrollada.
Publicacin: Por ltimo, el autor debe presentar la tarea
desarrollada cuando est lista para utilizar. Lo ideal sera que esto
no requiera ningn esfuerzo de administracin informtica.
Escenario de administracin. Finalmente, se necesita la
administracin de la plataforma de HPC. En este caso, consideramos
que las tareas principales para respaldar al usuario final comprenden
el monitoreo y la contabilidad y excluyen otras tareas de
administracin bsicas como configuracin del clster y otras
actividades generales de infraestructura informtica. (Ver Figura 4)
El escenario de administracin se puede describir de la siguiente
manera:
Publicacin:
Monitoreo: Por lo general, los clsteres son recursos compartidos

administrados por personal especializado. Ellos deben controlar
que las instalaciones proporcionen funcionalidad y rendimiento,
por ejemplo, analizar las colas de trabajo y las tendencias de
consumo de recursos.
Cuenta: Es recomendable justificar el uso de la utilizacin de
recursos por parte de ciertas cuentas. Esto ayuda cuando los
clsteres son financiados y utilizados por varios grupos.
Facturacin: Es posible crear modelos de cargo al usuario para
facturar su uso de un modo explcito.
Escenario de la solucin
Despus de haber detallado varios escenarios generales que pueden
representar los requisitos para una solucin de HPC y considerando el

valor descripto al comienzo en la construccin de una solucin de HPC,
podemos ahora considerar algunos escenarios de la solucin para
cumplir con estos requisitos.
Informtica de alto rendimiento con la edicin de Microsoft
"Compute Cluster Server
El servicio fundamental necesario para la solucin es la capacidad de
los clsteres de la Informtica de Alto Rendimiento en s. La edicin de
Microsoft Compute Cluster Server (CCS) ofrece capacidades de
clsteres para cumplir con el paso Proceso del escenario del
problema. (Ver Figura 5)
CCS brinda capacidades de clsteres para una versin reducida de
Windows Server 2003 que permiten, por ejemplo, el uso de
procesamientos paralelizados, aprovechando varios procesadores para
completar procesamientos particularmente complejos o intensivos
como aquellos que se basan en estadsticas generales.
El control de un clster de CCS es realizado por un nodo principal
que se comunica con los nodos del clster para impartir instrucciones y
coordinar una serie de tareas sobre un trabajo especfico. Los nodos del
clster pueden estar en una red privada, para un desempeo ptimo, y
probablemente sea una red de tiempo de espera mnimo para asegurar
que el tiempo de espera de red no tenga un impacto sobre el tiempo
del procesamiento. La seccin de recursos al final de este documento
contiene vnculos hacia artculos tcnicos sobre la configuracin e
implementacin del CCS.
El nodo principal posee un programador de tareas que permite la
insercin de una tarea de procesamiento dentro de una cola para que
se ejecute cuando la cantidad necesaria o deseada de procesadores
estn disponibles para completar la tarea. Se proporciona una base de
datos pequea al nodo principal para mantener un seguimiento de la
cola de tareas en curso. Se puede acceder al programador de tareas
mediante una interfaz en el nodo principal, va lnea de comando, que
se puede parametrizar o ejecutar con una definicin de XML de los
parmetros, o va API (CCS API) para interaccin programtica.
Un clster CCS puede controlar diferentes tipos de trabajos como los
que se detallan a continuacin:
Trabajo en serie: sta es una tarea de procesamiento habitual que

simplemente ejecuta un programa necesario.
Flujo de tareas: Varios trabajos en serie compuestos de mltiples

tareas/programas en potencia.
Figura 5: Microsoft Cluster Compute Server Edition satisface el paso del proceso.
Acceso
Solicitud
Proceso
Anlisis
Inicio de sesin
Carga
Preproceso
Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
Aprobacin
Postproceso
Descarga
Usuario
11
Consideracin de la cadena de valor

Por lo general, los usuarios de soluciones de informtica de alta
productividad son altamente cualificados y son recursos muy
preciados para los equipos de investigacin y desarrollo. Sus
habilidades y experiencia profesional son necesarias para brindar
aportes en los procesos, algoritmos para los clculos y el anlisis del
producto resultante. Sin embargo, se debe permitir que estos
recursos trabajen lo ms eficaz y eficientemente posible.
La creacin de soluciones poco claras, de un modo u otro,
afectaran esto de varios modos posibles:
Es posible que el usuario deba tener cierto conocimiento del
sistema que va ms all de lo que habitualmente se esperara. Por

ejemplo, necesito saber los principios bsicos de un control remoto
para poder operar mi televisor, pero para mirar televisin, no
necesito saber el voltaje requerido para activar su pantalla de LCD.
Los expertos que han participado de una solucin individual pueden
encontrar difcil liberarse de eso. Por ejemplo, si Alicia ha
codificado un algoritmo para la solucin, puede encontrar que est
muy involucrada en la operacin diaria de la solucin porque slo
ella comprende el mejor modo de interactuar con el sistema para
utilizar el algoritmo. Ella debera realmente dedicarse a crear
algoritmos an mejores. El resultado despus de una o dos
creaciones de mejoras no slo representa un alto costo en la
operacin de la solucin, sino tambin un problema de riesgo ya
que Alicia se ha vuelto un componente fundamental de la solucin.
La solucin tambin puede ser un problema en lo que respecta a la
administracin para los equipos fundamentales de informtica. Una
solucin de HPC creada con gran destreza por expertos en dominio
podra fcilmente ser anloga para las soluciones de hojas de
clculo vinculadas del equipo de ventas que puede ser
problemtico para cualquier desarrollo interno o para los equipos
de soporte.
La compresin de la cadena de valor en lo que respecta a tiempo y

costo debe ser la inquietud principal para la provisin de la solucin.
Dados los problemas detallados con mejoras en la velocidad para el
trabajo informtico, las mejoras deben identificarse fuera de este
mbito y en otras reas del proceso.
Candidatos ideales para la reduccin del costo en el proceso son,
ampliamente, todos los aspectos de la cadena de valor con la probable
excepcin de la creacin del algoritmo, que es la invencin y propiedad
intelectual de la solucin. La reduccin de costos se divide en dos
partes: el costo para utilizar la solucin y el costo de administracin.
Mejorar el proceso para la publicacin y uso de algoritmos, y brindar
soporte analtico podra reducir el costo total del proceso.
A partir de la consideracin de la cadena de valor, un conjunto de
soluciones debe estar compuesto de herramientas que proporcionen
dos caractersticas fundamentales: simplificar la finalizacin de la tarea
y oportunidades para la interaccin mejorada.
Una cadena de valor mejorada
Proporcionar una solucin basada en HPC utilizando una arquitectura
similar a la descripta puede tener varios beneficios para la cadena de
valor total. (Figura 2)
Existen varias reas que podran estar afectadas inicialmente:
Planificacin para un trabajo de larga ejecucin. Las reducciones de
Publicar
Publicar
Publicar
tiempo y gastos son posibles mediante el uso de interfaces

intuitivas, validacin y otra lgica para garantizar la captura de
informacin adecuada. Adems, los administradores o codificadores
especializados pueden ya no ser necesarios en esta instancia del
proceso.
Publicar un trabajo de larga ejecucin. Tanto el tiempo como los
gastos se pueden reducir debido a que la informacin es capturada
El diagrama de la Figura 1 representa el proceso de alto nivel para la
por el sistema y, por lo tanto, la publicacin del trabajo
provisin y uso de una solucin de HPC.
puede automatizarse
completamente
Figura 1: Cadena de valor original
Costo de la informtica. El costo
se reduce mediante la
Cadena de valor original
Ejecucin del flujo de trabajo (interactivo debido a regs de las
especializacin de las funciones
secuencias de comandos)
Costo
el monitoreo puede ocurrir desde
Tiempo
la perspectiva de un usuario
de
final y el costo total entre varios
Crear flujo de
trabajo Crear actividad
Analizar
trabajo
trabajos puede reducirse
Tiempo
mediante el reconocimiento
Tiempo
mejorado de trabajos errneos o
de
Publicar
Publicar
espera
fallas que pueden cancelarse
antes de haber finalizado la
Costo
ejecucin. Este reconocimiento
Ahorro neto = rea de la cadena original - rea de la cadena nueva
mejorado es nuevamente
proporcionado por el uso del
monitoreo y mecanismos de
feedback que se presentan a la
Figura 2: Cadena de valor mejorada
interfaz del usuario.
Anlisis. El anlisis se puede
Feedback anterior va
visualizadores
Cadena de valor nueva
iniciar de un modo ms rpido si
Costo reducido mediante la
Simplificacin mediante
especificacin del rol
sistema consolidado
la interfaz del usuario presenta
Cost
informacin durante la ejecucin
Tiempo
de
del trabajo; puede estar
Crear
trabajo
Analizar
Crear flujo de
algoritmo
disponible algn anlisis
Ejecucin del flujo de trabajo
Tiempo
trabajo
automtico que reduce los costos
Tiempo
Ejecucin
Ejec.
iniciales antes de que se necesite
del flujo de
del
de
Costo reducido mediante la
trabajo
FT
intervencin especializada.
espera
especificacin del rol
Costo
Ejecucin del flujo de trabajo

Tiempo reducido mediante
la automatizacin
12
Figura 6: Workflow Foundation puede brindar una capa de aplicacin completa que abarque la mayora de las reas en los pasos de Solicitud,
Proceso y Anlisis.
Acceso
Solicitud
Proceso
Anlisis
Inicio de sesin
Carga
Preproceso
Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
Aprobacin
Postproceso
Descarga
Usuario
Anlisis paramtrico: Este tipo de trabajo podra ejecutar varias
instancias de un nico programa pero con una serie de parmetros

diferentes, permitiendo varios resultados en el mismo perodo de
tiempo como una tarea nica.
Tarea de interfaz de paso de mensajes: El trabajo ms sofisticado
sera el uso de una Interfaz de Paso de Mensajes (MPI) para
paralelizar un algoritmo y dividir el trabajo del procesamiento entre
varios procesadores que se coordinan para proporcionar aumentos
de velocidad en procesamientos complejos y largos.
Varios o todos estos tipos de trabajo se pueden encontrar dentro de
un nico proceso de informtica. CCS debe poder ofrecer una
plataforma slida para cualquiera de las tareas de pre- o postprocesamiento as como tambin la tarea principal de procesamiento.
Lgica de aplicacin con Windows Workflow Foundation
Ya que podemos considerar que el proceso informtico total es una
instancia de un flujo de trabajo de mquinas y personas de larga
duracin, podemos considerar a Windows Workflow Foundation (WF)
como el punto de inicio para la construccin de una estructura y capa
de aplicacin de la solucin de HPC. En realidad, HPC posee varios
componentes que se pueden utilizar para proporcionar una capa de
aplicacin completa para la solucin de HPC. Las reas particulares
(pero no exhaustivas) que puede cubrir el WF se muestran en la
Figura 6.
WF forma una parte fundamental del marco de trabajo .NET 3.0 y
ofrece un motor de flujo de trabajo completo que se puede alojar en
varios entornos. La seccin de recursos de este artculo contiene
varios vnculos para obtener ms informacin sobre el Windows
Workflow Foundation.
Algunas de las caractersticas principales del WF para considerar son
las siguientes:
Flujos de trabajo de estado y en secuencia: El tiempo de ejecucin
del WF puede administrar flujos de trabajo orientados al estado y

secuenciales, por lo tanto, se pueden describir una gran variedad
de procesos. Estos flujos de trabajo tambin pueden gestionar
excepciones y reintentos.
Bibliotecas de actividades: Los flujos de trabajo estn compuestos
de actividades como toma de decisiones, ejecucin de bucles y
ejecuciones en paralelo, as como tambin, actividades de cdigo
arbitrario y varias de estas actividades estn listas para usar en el
.NET 3.0. Adems, debido a que el WF se utiliza para productos de
servidor muy eficaces (por ejemplo, Microsoft Office SharePoint

Server 2007), estos productos poseen actividades bsicas para
utilizar dentro del WF. Finalmente, las actividades se pueden
construir en la medida que sean necesarias para crear una
biblioteca individualizada y cumplir con un requisito especfico.
Motor de reglas: WF posee un variado motor de reglas de
encadenamiento progresivo que se puede utilizar para la toma de
decisiones dentro de un flujo de trabajo, pero tambin se puede
ejecutar fuera de las instancias del flujo de trabajo. Las actividades
se disean para que funcionen con este motor de reglas.
Diseador y realojamiento: WF tambin posee una superficie de
diseo completa de arrastrar y soltar que se utiliza dentro de
Visual Studio 2005 pero tambin puede ser realojada dentro de, por
ejemplo, una aplicacin de formularios de Windows.
Servicios en tiempo de ejecucin: El tiempo de ejecucin del WF
puede contar con servicios que han sido incluidos antes de la
ejecucin del flujo de trabajo para interceptar la ejecucin de un
flujo de trabajo y desempear acciones como persistencia o
seguimiento. Los servicios tambin se pueden construir en la medida
que sean necesarios.
Lenguaje de Marcado de Aplicaciones Extensible (XAML): Por ltimo,
WF utiliza en gran medida el XAML para describir flujos de trabajo y
conjuntos de reglas, lo que significa que la serializacin es trivial y
que realmente es posible la generacin de administradores de reglas
y superficies de diseo individualizadas.
Dadas estas caractersticas, podemos ahora ver el modo en el que WF

ofrece capacidad a la arquitectura.
Bibliotecas de actividades
Las bibliotecas de actividades son los bloques de construccin
necesarios para la solucin del HPC. Algunos ejemplos son los
siguientes:
Comunicacin del clster. Es posible crear una actividad
personalizada que utilice la interfaz de programacin de la aplicacin

CCS para comunicarse con el programador de tareas y crear o
cancelar trabajos en el clster. Esta actividad personalizada puede
entonces ser utilizada por cualquier flujo de trabajo que necesite
comunicarse con el programador de tareas y proporcionar un nivel
ms alto de abstraccin para los usuarios avanzados quienes
pueden necesitar crear nuevos flujos de trabajo o corregir los
existentes sin conocimiento detallado de programacin.
13
Arquitectura de Componentes
La arquitectura principal se parece a la conocida arquitectura de
aplicacin de n-capas y, en lneas generales, ste es de hecho el
caso. La organizacin de la funcionalidad es bastante lgica. La Figura
1 muestra los componentes necesarios para la arquitectura.
Capa de aplicacin
La capa de aplicacin est compuesta por el tiempo de ejecucin del
WF alojado como un servicio NT. Esta capa se utiliza principalmente
para comunicarse con el programador de tareas del clster, pero ofrece
una variedad de funciones:
Figura 1: Componentes
Biblioteca de flujos de trabajo y actividades para controlar el clster
y realizar movimientos de datos y otros pasos pre y post

procesamiento.
Motor de reglas y polticas para administrar el acceso a un clster y,
potencialmente, proporcionar prioridades y capacidades de metaprogramacin y seguridad.
Informacin de seguimiento para la ejecucin de trabajos brindando
informacin documentada, segn sea necesario.
Informacin de persistencia que permita escalar la solucin y
proporcionar eficacia a los flujos de trabajo de larga duracin y,
potencialmente, la capacidad de volver a ejecutar un flujo de trabajo
desde un estado en particular.
Arquitectura de componentes (con protocolos de comunicacin)

Interfaz de usuario
Ejecucin
ASP NET
PowerShell
WPF
Formularios de
Windows
Administrador de operaciones
de Microsoft
Extensiones WF SCC API
Ejecucin
(PCT) FCW
Administracin
MO SS 2007
Formularios de Windows
Tiempo de ejecucin del flujo de trabajo
Biblioteca de actividades
PCT
Visual Studio 2005
(PCT)
FCW
Autora
Registro
Servicio de datos
Servidor SQL
Resultados DB
Registro DB
Almacn de
archivos
Callogo de flujos de
trabajo DB
Servicio de datos
El servicio de datos contiene bases de datos de soporte como
almacenes persistentes y seguimiento para el tiempo de ejecucin del
flujo de trabajo. En esta arquitectura, tambin es probable que exista
un almacn que contenga resultados o agregados a resultados. Es
posible que los archivos de entrada y salida de datos se traten como
archivos para mover de un modo ms fcil los clsteres hacia los nodos
de proceso respectivos. Finalmente, hay una base de datos que
contiene un catlogo de los flujos de trabajo disponibles para su
ejecucin.
(PCT)
FCW
(PCT)
FCW
Persistencia
Servicio de cmputos
Programador de tareas
C, C++, MPI
Persistencia DB
Interfaz de usuario
La experiencia de la interfaz de usuario puede dividirse en tres
partes. Cada una desempea una funcin diferente de la solucin
general:
Servicio de cmputos
El servicio de cmputos es el ms simple de la arquitectura y est
compuesto de un clster de x nodos en una configuracin determinada.
La experiencia de usuario principal para planificar y ejecutar un
procesamiento puede proporcionarse mediante varias tecnologas.

Algunos ejemplos podran ser Windows Forms, Windows
Presentation Foundation, ASP.NET o Microsoft Office SharePoint
Server. La eleccin de la tecnologa debe ser apropiada para las
caractersticas de un entorno particular (por ejemplo, el uso de
tecnologas de Web en las que se requiere amplia disponibilidad o
WPF en el que se necesita una interaccin muy variada).
La experiencia de autora del flujo de trabajo es proporcionada por
Visual Studio 2005 que utiliza la superficie de diseo de autora del
Windows Workflow Foundation (WF). El uso del modelo code
beside (cdigo al lado) de los flujos de trabajo en desarrollo
permite utilizar una nueva interfaz API de Control de Cdigo Fuente
para enviar archivos XAML de WF hacia un depsito de bases de
datos central, por ejemplo, para ejecutar en la interfaz de usuario.
Para los administradores informticos, el Microsoft Operations
Manager puede utilizarse para controlar el buen funcionamiento y
el estado del clster de HPC, si bien para los usuarios finales de un
sistema HPC, se pueden poner a disposicin observaciones ms
comprensibles para el usuario mediante el uso de Windows
PowerShell.
Comunicacin
La comunicacin en todo el proceso de arquitectura se gestiona
utilizando Windows Communication Foundation mediante un TCP
(conexin remota) o un canal HTTP. Esto mantiene a la arquitectura
escalable y desacoplada y ofrece beneficios para las interfaces de
usuario diferentes, segn requisitos del usuario (autora, ejecucin,
emisin de informes).
Actividades del trabajo de clster fuertemente tipeados, de ms
Los flujos de trabajo para escenarios informticos especficos se

pueden juntar utilizando una combinacin de estas actividades
genricas y alguna actividad especfica para posibilitar el escenario
deseado.
Las actividades del flujo de trabajo cumplen todas las reglas
habituales de legado, por eso, vale la pena tener en cuenta que es
posible confeccionar un entorno heterogneo para una interfaz general
y luego seleccionarlo (en el momento del diseo o tiempo de ejecucin)
para permitir la ejecucin de un determinado clster. Un ejemplo
conveniente para esto sera crear una actividad que permita la
ejecucin de un procesamiento MPI sobre una mquina local tal vez,
utilizando dos procesadores para la evaluacin.
14
alto nivel que tratan archivos ejecutables especficos (en vez de

arbitrarios).
Actividades para los movimientos de datos en la red, posiblemente,
utilizando WF para controlar los servicios de integracin del
servidor SQL.
Carga de datos y actividades FTP, para resultados del movimiento.
Recuperacin en el caso de que ocurra alguna falla en el proceso.
Actividades de notificacin para eventos durante el proceso.
Actividades basadas en reglas para controlar la optimizacin
automatizada del proceso o privilegios de acceso.
Seguridad
En una estructura distribuida orientada al servicio, que potencialmente
pasa por varios dominios de seguridad, es fundamental la federacin
de identidades para permitir el control de acceso a nivel del usuario y
el inicio de sesin nico para todos los aspectos de la arquitectura de
componentes. Las tecnologas que ofrecen estas capacidades son
aquellas que estn basadas en certificados, federacin de directorio
activo (junto con extensiones para integrarse con los sistemas Unix) y
Windows CardSpace de Microsoft.

eventos y rellamadas del clster y luego realizar
actividades nuevas dentro de un flujo de trabajo.
Por ejemplo, el servicio de monitoreo puede
examinar una excepcin durante el procesamiento
o se puede utilizar para cancelar un procesamiento
que se est ejecutando sobre el clster.
Figura 7: Con el uso de la capa de aplicacin basada en WF, Windows Presentation

Foundation (izquierda) y Microsoft Office Sharepoint Server (derecha) ofrecen
experiencias de usuario diversas.
Se podran construir servicios adicionales junto con

estos. Un ejemplo sera un servicio de facturacin
que monitorea las duraciones del uso del
procesador y factura a un usuario en
consecuencia.
Seguridad y poltica
WF posee un motor de reglas de encadenamiento
progresivo eficaz que puede utilizarse dentro de
una instancia de flujo de trabajo. Se pueden crear
reglas en cdigo, o de forma declarativa, y luego
compilarlas junto con el flujo de trabajo para su
ejecucin.
Servicios
WF ofrece varios servicios que pueden utilizarse en la medida que
sean necesarios mediante la asignacin de la implementacin del
servicio al tiempo de ejecucin del flujo de trabajo. Tres de los ms
tiles para HPC son:
Servicio de seguimiento. Utiliza la nocin de perfiles de
seguimiento y un esquema de base de datos estndar para

controlar las ocurrencias en un flujo de trabajo. Esto se puede
ampliar en caso de ser necesario o reemplazar completamente con
una implementacin personalizada. El servicio listo para usar, por
lo general, es suficiente para proporcionar una auditora bien
detallada de la ejecucin del flujo de trabajo.
Servicio de persistencia. Utiliza un esquema de base de datos
estndar para comprimir o expandir las instancias del flujo de
trabajo, en la medida que lo necesite el tiempo de ejecucin, o
segn lo especifique el host. La expansin de un flujo de trabajo en
ejecucin sucede cuando ocurre un evento en ese flujo de trabajo,
haciendo que el WF sea un controlador ideal para flujos de trabajo
de larga duracin, como semanas, meses o grandes
procesamientos. La persistencia tambin proporciona escalabilidad
entre las mltiples aplicaciones de control y permite el uso de
grupos de cambio para restaurar un flujo de trabajo a una
posicin almacenada anteriormente y volver a ejecutarlo desde all.
Potencialmente, esto posee beneficios significativos para
procesamientos complejos de varias etapas y para volver a
ejecutar procesamientos de investigacin cientfica en un
determinado estado.
Servicio de monitoreo del clster. Este servicio puede registrar
Las reglas y las polticas pueden tener diversos usos:
Identidad del usuario. Podra concederse acceso a recursos del
sistema o a tipos de recursos basndose en la identidad, o se

podran agregar y eliminar pasos en un flujo de trabajo o servicios
segn la identidad.
Optimizacin. Se podra proporcionar cierta automatizacin para un
proceso de negocio u optimizacin mediante el uso de reglas
combinadas con inteligencia comercial u otros parmetros conocidos
para finalizar o eliminar pasos en un flujo de trabajo, segn sea
necesario.
Metaprogramacin. CCS no posee en la actualidad un
metaprogrmador, pero el WF podra utilizarse para designar la
ejecucin de clsteres particulares segn los parmetros, como
cantidad necesaria de procesadores o estado actual de los clsteres
disponibles, o identidad del usuario.
Por lo tanto, WF posee una flexibilidad y eficacia significativa. Tambin
analizaremos ms adelante el modo en el que podemos utilizar las
funciones del WF para ofrecer una experiencia de autora.
Experiencia del usuario con Microsoft Office SharePoint Server
Si utilizamos el WF para proporcionar la lgica de la aplicacin y el
control del proceso significa que podemos utilizar cualquier tecnologa
para almacenar la lgica de la aplicacin desde ASP.NET para
Formularios de Windows hasta Windows Presentation Foundation
(WPF). Las imgenes capturadas de la Figura 4 muestran el uso de
Figura 8: Escenario de informtica con Microsoft Office SharePoint Server

Acceso
Solicitud
Proceso
Anlisis
Inicio de sesin
Carga
Preproceso
Automtico
Inicializacin
Ingreso de datos
Proceso
En lnea
Aprobacin
Postproceso
Descarga
Usuario
15
Implementacin genrica?
Figura 9: El Administrador de Operaciones de Microsoft puede

monitorear el buen funcionamiento del sistema del clster CCS
Si bien los aspectos de la arquitectura propuesta estn previstos para

la reutilizacin, es poco probable que la arquitectura pueda ser muy
genrica para simplemente ser reutilizada de escenario en escenario.
Es ms probable que la arquitectura represente un enfoque shell o
ball-and-socket: el desarrollo ser requerido en cada escenario
pero con varios enfoques y componentes reutilizables. En siguiente
Figura se muestra una proporcin especulativa (basada en la
experiencia de desarrollo) para componentes genricos a especficos.
Escenario de Administracin
Administrar
Monitoreo
Administrador
Cuenta
WPF y Microsoft Office SharePoint Server (MOSS), utilizando

respectivamente la misma capa de aplicacin basada en WF, aunque
ofrecen experiencias de usuario muy diferentes.
El uso de Microsoft Office SharePoint Server (MOSS) brinda un
nivel de solucin que contempla reas en los pasos de Acceso,
Solicitud y Anlisis (Figura 8). Los motivos son los siguientes:
Colaboracin. La investigacin y otros usos tpicos de HPC giran en
torno a actividades de colaboracin, y MOSS es extremadamente
variado en funciones en lo que respecta a permitir la colaboracin
en referencia con el concepto de sitios.
Acceso. Los grupos de investigacin pueden estar separados
geogrficamente, por lo tanto, una interfaz basada en la Web
ayuda a garantizar que la plataforma est disponible para todos los
usuarios. Se podra generar un valor comercial significativo si se
proporciona a usuarios remotos acceso a una plataforma HPC.
Extensibilidad. MOSS se puede ampliar de diversas formas, desde
la bsqueda y catalogacin de informacin hasta la construccin de
partes de Web que se inserten en la aplicacin principal. Esta
extensibilidad tambin proporciona una plataforma de desarrollo y
paradigma de usuario slidos y una estructura para toda la
solucin.
Flujo de trabajo. MOSS tambin es potenciado por WF, por lo
tanto, la sinergia entre las dos tecnologas es muy clara. Una
ventaja es que el tipo de habilidades que poseen los equipos que
manejan flujos de trabajo HPC y que manejan otros flujos de
trabajo comerciales es totalmente transferible.
Para cubrir los niveles necesarios podemos aprovechar varias
funciones de MOSS:
Acceso e Inicializacin. Las capacidades de usuario y de inicio de
sesin nico de MOSS proporcionarn efectivamente funcionalidad

para el acceso estndar. La inicializacin puede facilitarse
extremadamente mediante la creacin de sitios individualizados
que representen tipos de trabajos de informtica. Por lo tanto, un
usuario puede generar un sitio que represente un proyecto o un
trabajo y recibir la configuracin necesaria de las partes de Web
para solicitar, ejecutar o analizar un trabajo de informtica.
Adems, se pueden aprovechar las caractersticas de colaboracin
como los wiki o controles de presencia.
Solicitud y Ejecucin. Se podran disear formularios de Web
especficos para permitir la insercin de parmetros y realizar
solicitudes, pero, una mejor solucin, en lo que se refiere a
capacidad y flexibilidad, podra ser utilizar InfoPath. InfoPath ofrece
capacidades sofisticadas para formularios de Web y capacidades de
autora bien desarrolladas. Debido a que utiliza XML para mantener
la definicin del formulario y los datos para el formulario, tambin
16
Estas proporciones se podran explicar del siguiente modo:

Interfaz de usuario 50-50. Los aspectos ms importantes de la
interfaz de usuario controles de movimiento de archivos,
controles sobre la ejecucin del trabajo y monitoreo con mucha
probabilidad sean inmediatamente reutilizables y aplicables a
varios escenarios. La especializacin ser necesaria, al igual que
con la interfaz de usuario, para cualquier proceso determinado, en
particular con escenarios tan diversos como los procesamientos
HPC.
Capa de aplicacin 80-20. La capa de aplicacin est compuesta
de una serie de flujos de trabajos y actividades que se pueden
volver a vincular y organizar para un proceso particular. Con
cierto trabajo, es posible que varias de estas actividades y
elementos lgicos puedan ser reutilizados con ciertos datos
nuevos. Los ejemplos podran incluir actividades para el
movimiento de archivos, integracin de CCS, poltica y metaprogramacin. Tambin, varias herramientas de autora podran
ser vlidas para usuarios avanzados en cualquier escenario.
Capa de HPC 10-90. Muy
poco de la capa de HPC
Implementacin estndar
posee alguna reutilizacin
ya que cada algoritmo
Interfaz de
ser nico. Sin embargo,
usuario
los procesos de
50%
50%
instalacin y monitoreo
son reutilizables y
coinciden con los
Aplicacin
paradigmas existentes de
80%
20%
Microsoft.
Capa de datos 40-60.
Una vez ms, las

estructuras de datos
exclusivas sern
necesarias para cualquier
procesamiento
determinado, pero las
bases de datos de
facturacin, persistencia y
seguimiento, por
ejemplo, sern todas
aplicables de escenario a
escenario.
HPC
10%
90%
Datos
40%
60%
Proporcin Genrica - Especfica
puede aprovechar los servicios de Web para la presentacin, y el

uso de servicios de Web permite que los flujos de trabajo activen
aprobaciones a solicitudes de trabajo y ejecuciones de trabajo. WF
en s mismo puede utilizarse para definir flujos de trabajo de
aprobacin necesarios y est incorporado como parte de MOSS.
Anlisis. MOSS tambin es capaz de alojar servicios de generacin
de informes y el Business Scorecard Manager (pronto ser
PerformancePoint) para la emisin de informes del estilo de un panel
de informacin. Adems, los servicios de Excel se pueden acceder
va MOSS, haciendo que sea una plataforma ideal para realizar el
anlisis inicial.

Monitoreo con Microsoft Operations Manager y PowerShell
El producto principal para monitorear el buen funcionamiento del
sistema es Microsoft Operations Manager (MOM). Se puede utilizar el
MOM para monitorear el buen funcionamiento del clster del CCS del
mismo modo que se puede utilizar para otros entornos de servidores.
Adems, con PowerShell, se puede proporcionar un monitoreo simple
del usuario para los usuarios finales (Ver Figura 9).
Figura 12: Arquitectura tcnica de HPC
Interfaz de usuario
(Portal de Sharepoint, Formularios de Windows)
Ofrecer una experiencia de autora con Visual Studio 2005

Por ltimo, se puede ofrecer una experiencia de autora de primera
clase a travs de Visual Studio 2005, algunas de las cuales son
estndar y algunas necesitan desarrollo (Figura 10).
Capa de aplicacin
(Windows Workflow Foundation)
Desarrollar
La codificacin es necesaria para los algoritmos y las actividades de
autora, por lo tanto, Visual Studio 2005 es un entorno ideal para
utilizar la estructura .NET para extender las actividades o modificar la
interfaz de usuario, as como tambin para utilizar Microsoft MPI y
pilas en C++ para la codificacin de algoritmos en paralelo.
Para el desarrollo de flujos de trabajo, Visual Studio 2005 tambin es
la opcin preferida, aunque puede no ser tan adecuado para los
usuarios avanzados como lo es para los desarrolladores, debido a la
complejidad de la interfaz. Para los usuario avanzados contamos con
otras opciones:
Realojamiento del diseador. El diseador del flujo de trabajo
completo puede realojarse dentro de una aplicacin de Formularios

de Windows. Esta aplicacin podra contar con una serie de
funciones simplificadas, especficas, para garantizar que un usuario
avanzado pueda construir y configurar con facilidad plantillas para
el flujo de trabajo. Tambin se puede utilizar para ofrecer cierta
garanta de calidad adicional a las estructuras del flujo de trabajo
Figura 10: Escenario de autora con Visual Studio 2005

Escenario de autora
Desarrollar
Publicar
Actividades
Catlogo
Algoritmos
Configuracin
Flujos de
trabajo
Produccin
Autor
Usuario
avanzado
Figura 11: La superposicin de roles reduce costos
Autor
Usuario
avanzado
Usuario
Disminuye el costo de la capacidad
Servicio de datos
(Servidor SQL)
Servicio de cmputos
(Windows CCS)
limitando las actividades disponibles para un usuario avanzado.
Desarrollo del diseador. Por otro lado, debido a que las definiciones
de las reglas y el flujo de trabajo se pueden describir en XAML, se
podra construir toda una superficie de diseo nueva para
representar la construccin del flujo de trabajo. Una superficie de
diseo nueva es una gran opcin para un dominio que posee un
modo particular de diagramar procesos o en los que se requieren
otras opciones de alojamiento, por ejemplo, utilizar Windows
Presentation Foundation o las capacidades de Web de AJAX. La
seccin de recursos contiene un vnculo a una implementacin de
ASP.NET AJAX de la superficie de diseo.
Desde la perspectiva del desarrollo, podemos consolidar eficazmente

todos los desarrollos de plataforma en un entorno y especializar ciertos
aspectos mediante el uso de XAML para la definicin de los flujos de
trabajo. El uso de XAML tambin ofrece la posibilidad de publicar.
Publicar
En el caso de las actividades y algoritmos, el paradigma de publicacin
es efectivamente la produccin de un software, ya que es necesario
distribuir los binarios en consecuencia, aunque, debido al software muy
especfico que se est generando, se podra construir un mecanismo de
distribucin para recuperar las bibliotecas de un modo especfico,
segn sea necesario.
Tambin, puede valer la pena investigar la tecnologa ClickOnce de
Microsoft para la distribucin de una aplicacin de autora de un
usuario avanzado cliente pesado para automatizar las actualizaciones
de la biblioteca.
En el caso de la autora de flujos de trabajo, la publicacin podra ser
tan simple como transmitir las definiciones XAML resultantes a una
base de datos central y catalogar estas definiciones. El flujo de trabajo
puede ser recuperado por un usuario final desde la misma base de
datos o simplemente podra invocarse como el resultado de una
seleccin sobre la interfaz de usuario y luego compilarse y ejecutarse,
segn sea necesario. Como se describe en la prxima seccin, la
implementacin de este concepto significa que nuevos flujos de trabajo
podran potencialmente publicarse muy rpido ya que no se necesita
liberar cdigo (por lo tanto, no existen requisitos administrativos o
ciclos de produccin).
Esta capacidad se podra ofrecer como parte de una aplicacin
individualizada de usuario avanzado, o como un complemento de Visual
Studio 2005.
Compilacin del flujo de trabajo
Los flujos de trabajo de WF, por lo general, se compilan dentro de
conjuntos, y luego son procesados por el tiempo de ejecucin del flujo
17

de trabajo pasando un tipo que se ajuste al flujo de trabajo dentro del
tiempo de ejecucin para crear una instancia del flujo de trabajo. Sin
embargo, un flujo de trabajo puede ejecutarse desde un archivo de
marcado declarativo archivo XAML si es necesario, o compilado
sobre la marcha desde un XAML, junto con reglas.
Esto es til ya que permite que el autor de un flujo de trabajo
alguien con conocimiento sobre la codificacin de los flujos de
trabajo cree un flujo de trabajo que no es totalmente vlido tal vez
le falten algunos parmetros y lo guarde dentro de un archivo de
marcado. El archivo de marcado puede entonces ser modificado por
un usuario avanzado que le incorpora los parmetros necesarios (pero
tal vez no edite el flujo de trabajo en s). Una vez que el flujo de
trabajo es vlido, puede ser presentado, compilado y ejecutado por la
capa de la aplicacin.
Estos pasos pueden disminuir el costo de la ejecucin del proceso
permitiendo que los roles se superpongan (Figura 11); las tcnicas de
autora costosas no deben tomar parte en el paso de ejecucin del
proceso en el que se pueden aplicar tcnicas de configuracin menos
costosas.
Arquitectura tcnica
Los escenarios de la solucin pueden agregarse dentro de una
arquitectura tcnica (Figura 12). Conceptualmente, CCS debe
considerarse una puerta de enlace de servicios del mismo modo que
el servidor SQL brinda servicios a una aplicacin la solucin no est
centrada en CCS pero utiliza sus capacidades, segn sean necesarias.
De igual modo, estos servicios se abstraen desde una interfaz de
usuario mediante algn tipo de control de la aplicacin o capa de
lgica de negocios. Por lo tanto, dada la naturaleza de las
interacciones con la solucin HPC flujos de trabajo humano WF es
una eleccin adecuada como controlador para estos servicios.
WF tambin posee otros beneficios. Est diseado para ser alojado
segn sea necesario, por lo tanto, la capa de interfaz del usuario
podra ser una aplicacin de Windows o de Web confeccionada
especficamente para la tarea. En el ejemplo detallado anteriormente,
describimos Microsoft Office SharePoint Server como una interfaz
adecuada porque posee fuertes conexiones para WF y la integracin
con Office, incluido InfoPath, y las caractersticas de colaboracin de
MOSS, podran ser tiles en los dominios cientficos y de ingeniera.
La eleccin, por supuesto, debe estar basada en los requisitos de un
dominio determinado.
Conclusin
El diseo de informtica de alta productividad no es simplemente
cuestin de garantizar el mejor rendimiento para computar
resultados lo ms rpido posible esto es ms una expectativa que
una caracterstica del diseo. En el contexto de la cadena de valor
total, la arquitectura debe proporcionar valor desde otras reas, como
por ejemplo, facilitar el acceso y disminuir los costos de las
habilidades especializadas para operar el sistema.
Una arquitectura exitosa para las soluciones de informtica de alta
productividad requiere la consideracin del proceso total junto con
actividades intensivas de informtica y, por lo tanto, tal vez utilicen
varios componentes integrados para desempear aspectos
individuales del proceso. Microsoft Cluster Compute Server Edition es
fcil de incluir como una puerta de enlace de servicio dentro de una
estructura de aplicacin general de n-niveles y es simple para
integrar a travs de conexiones API o lneas de comando.
Otras tecnologas disponibles pueden brindar la base para una
solucin HPC. En particular, Windows Workflow Foundation es ideal
para proporcionar una interfaz de aplicacin al CCS ya que las
funciones y la extensibilidad del WF, como persistencia y registro, son
18
propicias para los requisitos de soluciones basadas en HPC. El uso de

WF tambin ofrece opciones disponibles de tecnologas de experiencia
de usuario para que sean aplicadas en un dominio determinado.
Recursos adicionales
Los siguientes recursos pueden ser tiles al considerar las tecnologas
que abarcan la solucin propuesta en el presente artculo:
Microsoft Compute Cluster Server 2003,
http://www.microsoft.com/hpc
Microsoft SQL Server 2005 (incluyendo SQL Server Integration
Services), http://www.microsoft.com/sql
Microsoft Windows Workflow Foundation, http://wf.netfx.com
Microsoft Windows Communication Foundation, http://wcf.netfx3.com
Microsoft Windows Presentation Foundation, http://wpf.netfx3.com/
Microsoft Office SharePoint Server 2007,
http://www.microsoft.com/sharepoint/
Microsoft Operations Manager, http://www.microsoft.com/mom
Microsoft Windows PowerShell, http://www.microsoft.com/powershell
Otros recursos a los que se hace referencia en este artculo:
CCS 2003 Technical Articles,
http://technet2.microsoft.com/WindowsServer/en/library/9330fdf8c680-425f-8583-c46ee77306981033.mspx?mfr=true
Essential Windows Workflow Foundation, http://www.
awprofessional.com/bookstore/product.asp?isbn=0321399838&rl=1
Implementing the WF design surface in ASP.NET (with AJAX),
http://www.netfxlive.com/
Whitepaper on WF Performance,
http://msdn2.microsoft.com/enus/library/Aa973808.aspx
Agradecimiento
Meter Williams (Microsoft Consulting Services, lectura)
Sobre los autores
Marc Holmess es arquitecto evangelista para el Centro de Tecnologa
de Microsoft en Valley Park, Reino Unido, donde se especializa en
trabajos de prueba de conceptos, arquitectura y diseo con una
variedad de clientes, socios y fabricantes de software independientes.
Recientemente, antes de unirse a Microsoft, Marc lider un equipo de
desarrollo importante como Jefe de Aplicaciones y de Web en BBC
Worldwide. Marc es el autor de Expert .Net Delivery with NAnt and
CruiseControl .Net (APress) y posee un blog en
http://www.marcmywords.org. Puede contactarlo en
marc.holmes@microsoft.com.
Simon Cox es profesor de mtodos computacionales en Computacional
Engineering Design Research Group dentro de la facultad de Ciencias
de la Ingeniera de la Universidad de Southampton. Posee un premio
MPV por Windows Server System Arquitecto de Infraestructura, dirige
el Instituto de Microsoft para Informtica de alto Rendimiento en la
Universidad de Southampton y ha publicado ms de 100 artculos.
Actualmente es jefe de un equipo que desarrolla y aplica la informtica
en proyectos de ingeniera y ciencia informtica interdisciplinaria de
colaboracin, como electromagntica informtica, cristales lquidos,
modelado del sistema terrestre, bases de datos biomolecurales,
algoritmos informticos aplicados e informtica orientada a servicios
distribuidos.
Infraestructuras
orientadas a pruebas
Por Mario Cardinal
Sntesis
Las empresas de software informtico deben cumplir dos
funciones construir y ejecutar software. Cada funcin
requiere un conjunto de habilidades diferentes. La diferencia
entre construir y ejecutar casi siempre se observa con
claridad en el organigrama. En el mbito de la arquitectura,
por un lado, hay arquitectos de aplicaciones que participan
en el desarrollo de software (construir), y por el otro,
arquitectos de infraestructura que participan en la operacin
del software (ejecutar). Como arquitecto de aplicaciones,
creo que ambos equipos deben aprender las mejores
prcticas del otro. Una de las mejores prcticas que un
equipo de infraestructura debe aprender del equipo de
desarrollo de software es expresar las decisiones de
arquitectura utilizando comandos de prueba.
Decisiones de arquitectura
La disciplina de arquitectura de software est basada en la idea de
reducir la complejidad mediante abstraccin y separacin de asuntos.
El arquitecto es la persona responsable de identificar la estructura de
los componentes fundamentales que por lo general se los considera
difciles de cambiar, as como tambin de simplificar las relaciones
entre esos componentes. El arquitecto reduce la complejidad
dividiendo el espacio del problema en un conjunto de componentes e
interfaces que sern cada vez ms difciles de cambiar en la medida
que el proyecto se desarrolla.
La nica forma de simplificar el software es estructurar todas las
interacciones de los componentes principales mediante interfaces y
aceptar el hecho de que estas interfaces ahora son casi imposibles de
cambiar. Si se selecciona un componente de software, entonces se
puede hacer fcil de cambiar. Sin embargo, el desafo es que es casi
imposible hacer que todo sea fcil de cambiar sin incrementar el nivel
de complejidad, como lo expres Ralph Johnson en el artculo que
Martin Fowler escribi para IEEE Software: Hacer que algo sea fcil
de cambiar hace que el sistema global sea un poco ms complejo y
hacer que todo sea fcil de cambiar, hace que el sistema completo
sea muy complejo.
Establecer interacciones de componentes globales mediante
interfaces es hacer que las decisiones de diseo sean irreversibles.
Este conjunto de decisiones de diseo sobre la estructura fsica y
lgica de un sistema, en caso de hacerlas de un modo incorrecto,
pueden provocar que el proyecto sea cancelado. La clave del xito es
proteger el sistema contra la inestabilidad. Los buenos arquitectos
conocen el modo de identificar reas de cambio en requisitos
existentes y la forma de protegerlas contra la irreversibilidad de la
arquitectura.
Documentar la arquitectura es explcitamente comunicar, sin

ambigedad, los conjuntos de decisiones de diseo irreversibles.
Documentacin no ambigua
La documentacin de las decisiones de arquitectura facilita la
comunicacin entre los interesados. stas son las personas que
poseen un inters legtimo en la solucin. Existen dos clases
interesados con diferentes necesidades en lo que respecta a
especificaciones de arquitectura. La primera clase de interesados son
las personas que toman decisiones, quienes necesitan saber sobre la
arquitectura para comprender las restricciones y limitaciones de la
solucin. Ejemplos de estos interesados son gerentes, clientes y
usuarios. La segunda clase de interesados es la de los
implementadores, quienes deben saber sobre estas mismas
decisiones para construir y ejecutar la solucin. Ejemplos de estos
interesados son los desarrolladores, ingenieros de sistemas y
administradores de sistemas.
Una especificacin narrativa escrita como un documento es la
documentacin perfecta para la primera clase de interesados. Para
ellos, hasta una especificacin sin formalidad publicada como un
PowerPoint de Microsoft es suficiente. Esto les proporciona una
visin de alto nivel de la arquitectura casi sin ambigedad en lo que
respecta a las restricciones y limitaciones de la solucin.
Sin embargo, una especificacin narrativa no es la documentacin
adecuada para la segunda clase de interesados. Esto no proporciona
a los implementadores informacin concisa sobre las decisiones de
diseo. Y, en caso de hacerlo en una especificacin formal muy
abundante, este documento no ser de inters para quienes toman
decisiones. La primera clase no est muy interesada en la estructura
interna de los componentes de arquitectura fundamentales. Sin
embargo, los implementadores s.
En mi experiencia como arquitecto de aplicaciones, he descubierto
que el modo ms fcil de comunicar toda la complejidad de una
decisin de diseo irreversible no es confeccionar un documento
narrativo sino confeccionar una prueba que explique el modo en el
que validara una buena implementacin. Cuando slo se utilizan las
palabras, es muy difcil para los arquitectos e implementadores
comprenderse entre s con confianza. Siempre existe una diferencia
en la forma en la que cada parte comprende el significado de una
palabra especfica.
A continuacin detallo un ejemplo simple para demostrar mi idea.
Supongamos que escribo, en la especificacin de arquitectura, la
siguiente decisin de diseo:
Se recuperarn datos slo del da anterior en caso de que haya una
avera en el disco o corrupcin de datos. Los usuarios debern volver
a insertar los datos perdidos para el da en curso.
Obviamente, los implementadores necesitan aclaraciones sobre mi
objetivo para poder implementar mi especificacin correctamente. A
continuacin, la misma decisin redactada para ellos:
19

Se deber realizar una copia de seguridad de la base de datos del
Servidor SQL todas las noches. En caso de restauracin, volveremos a Figura 1: Modelo de secuencias de comando de prueba para validar
almacenar la ltima copia de seguridad.
decisiones de diseo
Esta redaccin es mejor que la original pero todava existen zonas
poco claras. Puedo volver a escribir la descripcin una y otra vez y
proporcionar cada vez ms detalles para los implementadores.
Terminara redactando una especificacin detallada formal. Sin
embargo, una documentacin narrativa no ofrece un consenso
explcito sobre lo que es una implementacin exitosa. An con la
mejor de las intenciones, por lo general, los implementadores no
comprenden bien los subttulos de mi especificacin formal. Por
ejemplo, supongamos que la solucin que propuse era realizar copias
de seguridad en cintas y olvid dejarlo explcito. Qu sucede si los
implementadores realizan las copias de seguridad de la base de datos
del servidor SQL en discos? A menos que yo descubra esto durante la
revisin del diseo, no lo sabr hasta que el disco del servidor SQL y
el disco que posee la copia de seguridad se daen el mismo da.
En cambio, si escribiera un comando de prueba, podra establecer
un consenso explcito sobre el cumplimiento. Un comando de prueba
tiene xito o falla. Las pruebas permiten que los implementadores y
los arquitectos definan explcitamente el cumplimiento de requisitos a
partir de las especificaciones de arquitectura. Los implementadores
que desean aprender sobre la arquitectura pueden analizar los
comandos de prueba. Los comandos de prueba son artefactos
operativos que poseen menos probabilidad de incumplimiento de los
requisitos de la implementacin y por lo tanto, poseen menos
probabilidad de estar desactualizados.
Consenso explcito
El comando de prueba es una combinacin del procedimiento de
prueba y los datos de prueba. Los comandos de prueba son grupos de
pasos escritos que deben realizarse de forma manual o automtica.
Reflejan caractersticas que son fundamentales para el xito de la
arquitectura. Estas caractersticas pueden indicar el uso apropiado o
inapropiado de la arquitectura as como tambin los comportamientos
negativos que se deben detectar.
Como ejemplo concreto, la Figura 1 muestra dos comandos de
prueba simples que validan la siguiente decisin de diseo
irreversible:
Se recuperarn datos slo del da anterior en caso de que haya una
avera en el disco o corrupcin de datos. Los usuarios debern volver
a insertar los datos perdidos para el da en curso.
Un comando de prueba tiene xito o falla. Debido a que valida el
propsito del arquitecto, proporciona un consenso explcito sobre el
cumplimiento.
Secuencia de prueba 1
Intento: Recuperar falla del disco duro del Servidor SQL
Pasos:
1. Reemplazar disco duro defectuoso
2. Instalar base de datos en el servidor SQL
3. Recuperar copia de seguridad del da anterior desde la cinta (crear
esquema y datos)
Criterio de xito: Puedo encontrar al menos una orden con su
campo de actualizacin configurado para el da anterior en la tabla
orden
Secuencia de prueba 2
Intento: Recuperar corrupcin de datos
Pasos:
1. En una base de datos del servidor SQL existente, recuperar la
copia de seguridad de la cinta del da anterior (sobrescribir datos)
Criterio de xito: No hay rdenes que posean su campo de
actualizacin configurado para el da de hoy y puedo encontrar al
menos una orden con su campo de actualizacin configurado para el
da anterior en la tabla orden
Proteccin contara el cambio

Los comandos de prueba que expresan las decisiones de arquitectura
claves estn siempre relacionados con cosas que cambian. Las
principales reas de cambio se pueden dividir en tres categoras:
1.
Ejecucin: En esta categora, las variaciones sobre el monitoreo y

las operaciones son la mayor inquietud de los arquitectos de
infraestructura. Afectan todos los otros asuntos de ejecucin como
presentacin, procesamiento, comunicaciones y administracin de
estado:
Presentacin: Interesados que interactan con el sistema. Cmo

implementamos la interfaz de usuario? Necesitamos muchos
puntos de entrada? Son importantes los factores de calidad como
posibilidad de uso, composicin y simplicidad?
Procesamiento: Instrucciones que cambian el estado del sistema.
Cmo implementamos el procesamiento? Necesitamos soporte
transaccional? Y concurrencia?Son importantes los factores de
Figura 2: Fuentes potenciales de las variaciones del tiempo de ejecucin
Nodo de tiempo de ejecucin
y
y
y
Estilo
Implementacin
perspectiva del
usuario
y
y
y
Procedimiento, OO, norma,

declarativo
Simultneo/paralelo
Transaccional
Presentacin
Administraci
n del estado
Procesamiento
Presentacin
y
y
y
OO, relacional, XML

Ubicacin
Vigencia
Operacin y monitoreo
Administracin
Procesamiento del estado
Comunicacin
y
y
y
Transportar
Cambiar
Formatear

Operacin y
monitoreo
Presentacin
Administracin
Presentacin
Administracin
calidad como disponibilidad,

escalabilidad, rendimiento y
fiabilidad?
Comunicacin: Distribucin de
estado entre los nodos fsicos del
sistema. Cmo interactuamos? En
qu formato viajan los datos?
Sobre qu medio se realiza la
comunicacin? Son importantes los
factores de calidad como la
seguridad y la manejabilidad?
Administracin de estado: Ubicacin,
vigencia y forma de los datos.
Necesitamos un estado transitorio o
duradero? Cmo guardamos el
estado? Son importantes los
factores de calidad como
disponibilidad, capacidad de
recuperacin, integridad y
extensibilidad?
La Figura 2 es un diagrama que muestra

todos los orgenes potenciales de las
variaciones del tiempo de ejecucin.
20
2.
3.
Los arquitectos protegen el sistema contra la inestabilidad del

tiempo de ejecucin mediante la construccin de abstracciones.
Las pruebas deben validar estas abstracciones. Por ejemplo, en
los requisitos de alta disponibilidad, una solucin demostrada
para la proteccin contra defectos de un servidor fsico es poner
en prctica un sistema de fallas. El sistema de fallas posee la
capacidad de pasar de un modo automtico a un servidor
informtico en espera a partir de la finalizacin anormal o falla
del anterior servidor activo.
Utilizacin. Estos son los asuntos de tiempo de carga. En esta
categora, los arquitectos de infraestructura deben prestar
atencin a las variaciones de registro y configuracin. Por
ejemplo, para proteger contra los cambios en mecanismos de
autenticacin cuando se utiliza Windows como una plataforma,
una solucin demostrada es almacenar las credenciales del
usuario en Microsoft Windows Active Directory.
Implementacin. Las variaciones ms importantes de tiempo de
diseo estn relacionadas con inestabilidad en la planificacin y la
organizacin (personas). Por ejemplo, los equipos de
infraestructura han aprendido el modo de protegerse contra
equipos de desarrollo inestables. La implementacin de
componentes de mala calidad en la produccin puede ser grave
para los acuerdos de nivel de servicio. Una solucin demostrada
es establecer un mecanismo de feedback para restaurar
rpidamente el sistema al estado estable anterior. No slo se
deben documentar los procesos de feedback sino que tambin se
deben confeccionar pruebas para expresar el cumplimiento sin
ambigedad.
El proceso de descubrimiento de decisiones de diseo irreversibles

est compuesto de la revisin de todas estas reas susceptibles al
cambio y la construccin de las pruebas apropiadas.
Artefactos operativos
En la actualidad, los comandos de prueba pueden ser manuales,
automticos o una combinacin de ambos. La ventaja que posee la
prueba automatizada sobre la manual es que es fcilmente repetible.
Por lo tanto, se las prefiere cuando se realizan pruebas de regresin.
Cuando se modifica el software, ya sea para realizar un cambio en la
funcionalidad o para solucionar defectos, la prueba de regresin
vuelve a ejecutar las pruebas finalizadas anteriormente. Esto
garantiza que las modificaciones no hayan causado involuntariamente
un descuido de las decisiones de diseo.
Un comando de prueba automatizado es un programa breve escrito
en un lenguaje de programacin. Los arquitectos de infraestructura
no necesitan ser programadores para escribir una prueba
automatizada. Los lenguajes de secuencias de comandos pueden
realizar el trabajo eficazmente. Cuando se utiliza Windows como
plataforma, PowerShell, el nuevo lenguaje de secuencia de comandos
y shell de comando de Microsoft, es ideal para estos propsitos
debido su soporte para las estructuras de control, manejo de
excepciones y acceso a clases del sistema .NET. A continuacin se
detallan algunos ejemplos de prueba para los que se podra utilizar
PowerShell:
Prueba de implementacin. Crea un comando que verifica que la

produccin haya sido como se esperaba; verifica los procesos en
ejecucin, servicios, metadatos de la base de datos, contenido de
la base de datos, versiones de los archivos de aplicacin,
contenidos del archivo de configuracin, etc.
Prueba de infraestructura. Crea un comando que verifica el
hardware, sistema operativo, servicios en ejecucin, procesos en
ejecucin, etc.
Por ejemplo, a continuacin se muestra una breve funcin del

PowerShell para probar la conectividad hacia un servidor:
function test-connection
{
$pingtest = ping $args[0] -n 1
if ($pingtest -match TTL=)
{
write-host $true
}
else
{
write-host $false
}
}
Usage:
test-connection MyServer01.domain.com
A diferencia de un documento narrativo, un conjunto de comandos de
prueba automatizados es un artefacto operativo. Siempre se mantiene
actualizado y valida continuamente el cumplimiento del objetivo del
arquitecto.
Diseo con capacidad de pruebas
La capacidad de pruebas significa contar con interfaces apropiadas y
seguras para orientar la ejecucin y verificacin de los comandos de
prueba. No se puede lograr la capacidad de prueba si se confeccionan
pruebas despus del diseo y la implementacin. Construir pruebas
durante el diseo es el nico enfoque posible para lograr la capacidad
de prueba.
Al abstraer la implementacin, si se confeccionan primero las
pruebas se reduce en gran medida el vnculo entre los componentes.
Las decisiones irreversibles de diseo ahora se pueden probar de un
modo mucho ms exhaustivo que antes, dando como resultado una
arquitectura de ms alta calidad que es tambin ms fcil de
mantener. De este modo, los beneficios mismos comienzan a producir
dividendos para el arquitecto, creando un ciclo ascendente perpetuo en
apariencia para la calidad. El hecho de confeccionar pruebas durante la
etapa de diseo brinda un doble beneficio:
1.
2.
Valida el cumplimiento del objetivo del arquitecto.

Lo hace de un modo explcito.
Las pruebas son un proceso de requisitos, no simplemente un proceso

de validacin.
Diseo con automatizacin
La experiencia ha demostrado que durante el mantenimiento de
software es muy comn la reaparicin de fallas. A veces, la solucin a
un problema puede ser frgil, es decir, no respeta caractersticas que
son primordiales para el xito de la arquitectura.
Por lo tanto, se considera una buena prctica registrar una prueba y
volverla a ejecutar regularmente despus de cambios posteriores en el
programa. Si bien esto se puede realizar mediante una prueba manual,
con frecuencia se realiza utilizando herramientas de prueba
automatizadas. Estas herramientas intentan descubrir errores en la
regresin. Estos errores ocurren siempre que la funcionalidad de un
software que anteriormente funcionaba segn lo deseado, deja de
funcionar o no funciona ms del mismo modo. Por lo general, los
errores en la regresin ocurren como consecuencia involuntaria de
cambios en el programa.
La prueba de regresin es una parte integral de la metodologa de
desarrollo de software gil, como eXtreme Programming. Esta
metodologa promueve la automatizacin de pruebas para construir
mejor software, ms rpido. Esto requiere que se escriba una prueba
de la unidad automatizada, definiendo los requisitos del cdigo fuente,
21
Figura 3: Prueba automatizada de PowerShell
set-psdebug -strict -trace 0

# Ensure that group App_Setup is defined in Windows Active Directory
function TestActiveDirectoryGroup
{
$objGroup =[ADSI]LDAP://localhost:389/CN=App_Setup,OU=HR,dc=NA,dc=org1,dc=com
AssertNotNull $objGroup App_Setup group is required to install application xxx.
RaiseAssertions
}
# run the function library that contains the PowerShell Testing Functions
# the functions are defined as global so you dont need to use dot sourcing
if (!(Test-Path variable:_TESTLIB)) { ..\src\TestLib.ps1 }
# run the function defined above that demonstrates the PowerShell Testing Functions
TestActiveDirectoryGroup
antes de cada aspecto del cdigo mismo. Las pruebas de unidad se

utilizan para usar otro cdigo fuente llamando directamente rutinas,
pasando parmetros apropiados y luego, si se han incluido Assert
statements, probando los valores producidos en comparacin con los
valores esperados. Las estructuras de prueba de unidad, como xUnit,
ayudan a automatizar la prueba en cualquier etapa del ciclo de
desarrollo.
La estructura xUnit se present como un concepto fundamental de
eXtreme Programming en 1998. Introdujo un mecanismo eficaz que
ayud a los desarrolladores a incorporar pruebas de unidad
automatizadas, eficaces y estructuradas dentro sus actividades
normales de desarrollo. Desde entonces, esta estructura ha
evolucionado como el estndar de facto para las estructuras de
prueba de unidad automatizadas.
La estructura xUnit ejecuta todos los comandos de prueba en
intervalos especficos e informa cualquier regresin. Estrategias
comunes son ejecutar ese sistema despus de cada construccin
exitosa (integracin continua), cada noche o una vez por semana.
Esto facilita el proceso de prueba de unidad y prueba de regresin.
Por lo general, es posible realizar la prueba sin el soporte de las
estructuras de xUnit mediante la confeccin de cdigo de cliente que
pruebe las unidades y utilice declaraciones, excepciones y
mecanismos de salida anticipada para indicar la falla. Sin embargo,
los arquitectos de infraestructura no necesitan confeccionar su propia
estructura de prueba. Las conocidas estructuras de prueba de xUnit
han sido desarrolladas para una gran variedad de lenguajes, incluido
el lenguaje de secuencia de comandos comnmente utilizado por el
administrador del sistema.
Sobre la plataforma de Windows, PowerShell Scripts for Testing,
una biblioteca de funciones que implementa el conocido xUnit-style
asserts para el nuevo shell de comando y lenguaje de secuencia de
comandos de Microsoft, puede descargarse gratis de CodePlex, un
sitio de Web que aloja proyectos de cdigo abierto (Ver Recursos). En
la Figura 3 se muestra un modelo de prueba automatizada con
Powershell.
Las pruebas automatizadas intentan descubrir, lo antes posible,
descuidos de las decisiones de diseo que son primordiales para el
xito de la arquitectura. Las pruebas automatizadas son:
22
Estructuradas
Auto-documentadas
Automticas y repetibles
Basadas en datos conocidos
Diseadas para probar acciones positivas y negativas
Ideales para probar la implementacin entre diferentes mquinas
Documentacin operativa de configuracin, implementacin y
ejecucin.
Prueba orientada a los datos

La automatizacin de la prueba, en especial en los niveles ms altos de
prueba como las pruebas de arquitectura, puede parecer costosa. Debe
existir un argumento econmico para respaldar el esfuerzo. El modelo
econmico puede debilitarse si no se simplifica el proceso de confeccin
de pruebas.
La prueba orientada a los datos es un modo de disminuir los costos
de la automatizacin de pruebas. Permite que el personal de pruebas
se concentre en la provisin de ejemplos mediante de combinaciones
de pruebas aportadas y resultados esperados. Uno disea la prueba
mediante la creacin de una tabla que contiene todos los datos de la
prueba (aportes y resultados esperados) y luego confecciona un
programa que transforma una fila de la tabla en una llamada al servicio
bajo prueba (SUT).
Uno logra el ndice de alto rendimiento en virtud de no tener nunca
que confeccionar el comando ms all de escribir el programa. La
estructura proporciona el comando de forma implcita, y lo ejecuta. En
la ltima versin de PowerShell Scripts for Testing, esta estructura de
xUnit posibilita el uso de Excel como fuente de datos para respaldar la
prueba orientada a datos. Existe una nueva funcin en DataLib.ps1
llamada start-test que toma como entrada un nombre de libro, un
nombre de hoja de trabajo, un nombre de mbito y un conjunto de
nombres de campos y ejecuta las pruebas que se describen en el
mbito. Esto se realiza mediante la llamada a una funcin que posee el
mismo nombre que el mbito.
El uso del start-test se muestra en una prueba de rendimiento
modelo en el blog complementario de PSExpect. La Figura 4 muestra
una tabla de Excel y comando de prueba proporcionado por el servicio
meteorolgico de Web.
Figura 4: Tabla de Excel y comando de prueba para el servicio

meteorolgico de Web
llegue al cliente. Cuanto antes se detecten los problemas, ms bajo

es el costo para solucionarlos ya que el rea de superficie del
cambio en menor (es decir, la cantidad de cambios desde la ltima
prueba ser limitada).
Garantiza fiabilidad: Las pruebas realizan exactamente las mismas
operaciones cada vez que se ejecutan, sin ambigedad. Esto puede
tener xito o fallar. Proporciona un consenso explcito sobre el
cumplimiento y valida continuamente el objetivo del arquitecto.
Elimina el error humano y evita el factor de esfuerzo que implican
las pruebas manuales en la medida que se acercan las fechas lmite.
Genera confianza: La automatizacin brinda un feedback concreto
sobre el sistema ya que se puede probar el modo en el que
reacciona el software a ejecuciones repetidas de las mismas
operaciones.
Evita riesgos: Las pruebas automatizadas demuestran la integridad
del sistema dentro de un plazo sensato. Las pruebas pueden
ejecutarse una y otra vez con menos gastos generales.
Mejora la capacidad de mantenimiento: Confeccionar pruebas
primero influye en la estructura y crea sistemas modulares. Reduce
en gran medida el acoplamiento entre los componentes,
disminuyendo el riesgo de que el cambio en un componente obligue
un cambio en otro componente.
Proporciona documentacin actualizada de un modo sistemtico: Las
pruebas son un artefacto operativo que no puede ser excluido de la
sincronizacin. Si las pruebas se alejan de la realidad, es imposible
ejecutarlas con xito. Las pruebas desactualizadas siempre fallan.
Recursos
Who needs an architect? Martin Fowler, IEEE Software Magazine,
Volume 20, Issue 5 (Septiembre 2003)
http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
CodePlex PowerShell Scripts for Testing
http://www.codeplex.com/psexpect
Companion blog for PSExpect:
http://testfirst.spaces.live.com
Conclusin
La prueba automatizada combinada con la prueba de regresin no
slo documenta las decisiones de arquitectura en el nivel adecuado
para los implementadores sino que tambin valida continuamente el
cumplimiento del objetivo del arquitecto.
Los beneficios de confeccionar pruebas automatizadas son los
siguientes:
Permite el cambio. En la medida que el sistema de software es ms

grande, se vuelve cada vez ms difcil realizar cambios sin afectar
cosas. El riesgo comercial para esta situacin es que uno puede
encontrarse en una situacin en la que los clientes piden cosas o el
mercado evoluciona de un modo que provoca la necesidad de
cambio. Una gran cantidad de comandos de prueba automatizados
da libertad a los arquitectos para hacer muchas cosas interesantes.
Los arquitectos tendrn menos temor de cambiar las decisiones de
diseo existentes. Con la prueba automatizada como una red
segura pueden refactorizar la arquitectura, o agregar o cambiar
funciones, por ejemplo, sin preocuparse. Lo que descubrir, al
invertir en pruebas automatizadas, es que su organizacin
realmente avanza ms rpido de lo que sola hacerlo. Puede
responder a los cambios del mercado con ms rapidez, introducir
funciones de un modo ms dinmico y contar con una organizacin
ms slida. La prueba automatizada lo ayuda a:
Reducir costos: La prueba automatizada detecta los problemas lo
antes posible de un modo eficaz, mucho antes de que el software
Sobre el autor
Mario Cardinal es consultor senior independiente especializado en
arquitectura de aplicacin empresarial. Dedica la mayor parte de su
tiempo a la construccin de aplicaciones.NET empresariales bien
diseadas con procesos giles. Cuenta con ms de quince aos de
experiencia en el diseo de sistemas de informacin a gran escala. Por
segundo ao consecutivo ha recibido de Microsoft el Premio al
Profesional ms Valioso (MVP) por sus cualidades como Arquitecto de
Software. El nombramiento de MPV se otorga a verosmiles expertos en
tecnologa quienes se encuentran entre los miembros ms destacados
de la comunidad dispuestos a compartir sus experiencias para ayudar a
otros individuos a desarrollar su potencial. Lidera el grupo de inters
sobre arquitectura en el Montreal Visual Studio User Group y en la sede
de la Asociacin Internacional de Arquitectos de Software (IASA, por
sus siglas en ingls) en Montreal. Tambin es moderador tcnico de la
seccin de Arquitectura para DevTeach Conference. Adems, es
anfitrin de un programa de debate en Internet sobre el desarrollo de
software con Microsoft .NET (Visual Studio Talk Show). Mario posee
diplomas de Licenciatura en Ingeniera Informtica y Master de
Administracin de Tecnologa otorgados por Ecole Polytechnique en
Montreal, Canad. Tambin posee los ttulos de Certified ScrumMaster
(CSM) y Microsoft Certified Solution Developer (MCSD.Net). (Puede
contactar a Mario a travs de su sitio de Web, www.mariocardinal.com)
23
Perfil del Architecture

Journal: Don Ferguson
Para esta edicin, como parte de la serie Perfil del

Architecture Journal tuvimos la oportunidad de ponernos al
da con Don Ferguson, Asociado Tcnico de Microsoft. Le
preguntamos a Don algunas cosas sobre su carrera y le
pedimos consejos para las personas de desean ser
arquitectos o para quienes hoy estn interesados en la
arquitectura.
AJ: Quin es y de dnde viene?

DF: Soy Don Ferguson. Antes de unirme a Microsoft a principios de
este ao, era Asociado de IBM. Hay aproximadamente 200.000
ingenieros en IBM y cerca de 50 Asociados, por lo tanto, fue un gran
honor para m ser uno de ellos. Cuando me un a IBM Research,
jams pens que algn da sera Asociado. Tal vez algn da podra
ser lder de proyecto esto ya sera un gran logro. Hay muchsimas
personas talentosas e inteligentes y yo slo esperaba poder ser uno
de ellos.
AJ: Qu se siente al llegar a ser un Asociado de IBM?
DF: El da que llegu a ser Asociado fue uno de los mejores das de
mi vida. Sin embargo, en verdad, me senta un poco avergonzado con
la condecoracin. Senta que haba algunas personas que lo merecan
ms que yo. Entonces, poco despus de la noticia llegu a ser
defensor de esas personas y, con el paso de los prximos pocos aos,
puede ayudar a tres o cuatro de ellos a que lleguen a ser Asociados.
De alguna manera, estaba ms feliz cuando ellos recibieron la
condecoracin que cuando yo recib la propia. Cuando le sucede a uno
mismo, es muy confuso, pero cuando les sucede a los otros es una
gran satisfaccin.
AJ: Cmo era un da tpico para usted?
DF: Yo era Arquitecto Principal del Grupo de Software en IBM. Haba
cientos de productos y proyectos. Ser Arquitecto Principal significa
que uno no puede disear cada componente. Existen realmente
demasiados productos y productos para que esto sea una meta
realista. Una gran parte de mi da sola dedicarla a realizar mucho
trabajo de revisin. Revisaba varios diseos de productos o
proyectos, concentrndome en algunas cosas de nivel ms alto. Haca
especial hincapi sobre los nuevos productos. Por lo general, me
enfocaba en la integracin de productos cruzados, temas comunes,
etc. Por ejemplo, Posee el producto del portal la interfaz correcta
para conectarse a este producto de seguridad? Soporta el producto
los estndares correctos? Sola referirme en broma a esto como
Pastorear gatos. En las diapositivas de las presentaciones que daba,
con frecuencia sola utilizar el ttulo Encargado de pastorear gatos.
Al principio, este trabajo era poco gratificante demasiado
abstracto, muy superficial, muy general. Pero despus, tuve una
epifana. Analizar las diversas partes ms como un todo, en vez de
considerarlas por separado, tena un efecto significativo, en especial,
24
entre los productos. Un poco de mejora en varios lugares hace la

diferencia. Un ejemplo real de esto es el trabajo que pude realizar
sobre los estndares de los Servicios de Web. Creo que ayud a
hacerlos un poco ms coherentes, fcil de componer y de
comprender.
AJ: Con tanta responsabilidad Cmo se mantiene informado
sobre la tecnologa?
DF: Buena pregunta! Lo primero que hago es trabajar realmente
mucho. Cuando no estoy con los nios, a menudo, como, duermo,
trabajo, hago karate y a veces, dormir es opcional. Segundo,
realizo muchas investigaciones sobre aviones en las que no hay
conferencias telefnicas ni interrupciones. Siempre que puedo, trato
conscientemente de mantenerme alejado del correo electrnico.
Tambin trato de no aprender la informacin tcnica nueva leyendo
artculos o presentaciones. El mejor modo es descargar, instalar,
utilizar y codificar.
Con el paso de los aos, una de las cosas que aprend a hacer
bien es sintetizar el modo en el que las cosas deben funcionar con
slo un poco de informacin. En general, las personas son
inteligentes. Con slo un poco de informacin, a menudo puedo
averiguar lo que habran hecho las personas inteligentes. Cmo
habran diseado esto las personas inteligentes? Con este proceso, si
bien no conozco el tema con detalle, a menudo puedo deducir la
forma en la que deberan funcionar las cosas y contribuir en el
debate.
En IBM, por lo general, sola tener cerca de 10-12 iniciativas sobre
las cuales trabajaba en cualquier momento. Sola dedicar algunos
meses para cada proyecto, multiplexando entre las iniciativas.
Finalmente, cada iniciativa prosperaba o no tena xito. Se ve
muchsimo de esto en los trabajos estndares en los que particip.
Estaba incluido como colaborador para varios de los primeros
artculos, pero con el tiempo desaparec. Muchas buenas personas
comenzaron a liderar y realizar los trabajos tcnicos intensos, y yo,
pas a hacer otras cosas.
AJ: Qu consejo le dara a alguien que desea ser un
arquitecto en la actualidad?
DF: Creo esta respuesta se divide en cuatro partes.
En primer lugar, en IBM tenamos un Consejo de Arquitectos en el
Grupo de Software que me ayud a formar una red. Me llev un
tiempo comprender la importancia de una red. Al ser de Nueva
Inglaterra, sola ser un poco reservado e independiente. Nunca se
debe subestimar la importancia de una red social. Uno no sabe lo
que no conoce. Uno no sabe lo que alguien puede decir que tal vez
puede presionar el botn de reinicio en nuestras mentes y nos puede
hacer pensar de un modo diferente.
Segundo, como arquitecto de software, nunca dejo de codificar.
Escribo cdigo. No es que sea buen cdigo o particularmente
profundo, pero creo cdigo. Mucho de esto es educativo y est
relacionado con las actividades de mi tiempo libre. Por ejemplo,
recientemente estuve trabajando en un portal que conecta a mi
Perfil del Architecture Journal: Don Ferguson

familia utilizando TikiWiki y PHP. Instal los productos, pero para m
no estaban listos para usar inmediatamente. Por lo tanto, tuve que
modificarlos. Fue interesante. Otro ejemplo es el jardn de infantes al
que asiste mi hija. Me pidieron que configura un sitio de Web
utilizando FrontPage, que fue otra experiencia de aprendizaje.
Tercero, la capacidad para comunicarse tiene importancia. En
realidad la tiene. Es realmente importante comprender el modo de
escribir bien y cmo presentar bien.
Finalmente, lo ms importante es conectarse con los clientes. Pasar
el mayor tiempo posible con ellos. Conocer lo que tratan de hacer y
analizar lo que funciona y lo que no. Ayudarlos a utilizar sus
productos. No hay nada mejor que dedicar tiempo a los clientes y
ayudarlos a resolver sus problemas. Al hacer esto, con frecuencia,
nos enterbamos que los clientes utilizaban cosas de un modo que
jams hubiramos imaginado que lo haran. Tambin, se nos ocurran
nuevas ideas asombrosas.
AJ: Quin es la persona ms importante que ha conocido y
qu hizo que esta persona sea tan significativa?
DF: Cuando me inici en el mundo acadmico y en la Divisin de
Investigacin, mi consejero para la tesis (Yechiam Yemini) fue
realmente importante. l me ense dos cosas:
Las personas perseverantes y decididas a tener xito solemos
subestimar la calidad de lo que hacemos. Somos muy exigentes con
nosotros mismos. Pensamos que nuestras ponencias no son muy
buenas y que nuestra investigacin no es novedosa. Mi consejero me
ayud con perspectiva.
Segundo, me ense que estas cosas pueden ser entretenidas
simplemente divirtanse y disfruten de lo que estn haciendo. l tena
un entusiasmo infantil muy contagioso.
Adems de mi consejero, hay varias personas en IBM que llegaron
a ser grandes amigos y ejemplos a seguir. Tony Storey fue el ms
importante. Yo sola analizar a quienes respetaba y con frecuencia
trataba de deducir el modo en el que realizaban sus trabajos.
Conscientemente trataba de ser como ellos.
AJ: Hay algo en su carrera de lo que se arrepiente? Qu
aprendi de eso?
DF: Wow! Incluso, no s por dnde empezar! Voy a comentar dos:
Mi grupo anterior me dio un casco de Darth Vader, por el modo en
el que trabajaba los primeros das. Hazlo a mi modo o har explotar
tu planeta. El enfoque de Darth Vader no funciona. No se puede
hacer que personas inteligentes hagan cosas que no desean hacer.
Las personas hacen bien lo que desean hacer. Para m esto era un
epitafio. Por qu yo era tan brusco y dominante? Estaba ocupado y
en todo lo que poda pensar era Tengo que hacer estas 20 cosas
Por qu esta persona no har lo que quiero? Me di cuenta que este
enfoque nunca funciona, no importa cunto uno lo intente. Las
personas merecan mi tiempo y yo les deba el tiempo.
Segundo, muchas personas que trabajan en la tecnologa sufren de
la falacia del final del juego Somos todos bastante inteligentes.
Dedicamos tiempo a muchos clientes. Analizamos lo que estn
haciendo y luego trazamos una lnea hacia el punto en el que estarn
en algunos aos. Sin embargo, una vez que se hace esto, es muy
tentador construir lo que necesitarn en cinco aos, y no lo que
necesitan prximamente o para lo que estn preparados ahora. A
veces digo que no tiene sentido construir la Ciudad Esmeralda sin
construir el Camino Amarillo de Ladrillos y primero se debe construir
el camino. Con frecuencia, haca las cosas muy complicadas,
anticipando sus futuras necesidades. Uno de los ejecutivos senior
sola decir La visin sin ejecucin es alucinacin y esto es verdad.
AJ: Cmo es el futuro de Don?
DF: Para responder a esto, tengo otro consejo. Cuando me pregunto
esto a m mismo, siempre pongo en primer lugar las realizaciones
personales y en segundo lugar las realizaciones profesionales. Si uno
no est realizado personalmente, nunca se realizar en su trabajo.
El Dr. Donald Ferguson es Asociado Tcnico

de Microsoft en Plataformas y Estrategias
en la Oficina del CTO. Don se enfoca en la
funcin evolutiva as como tambin en la
funcin revolucionaria de la informtica en
los negocios. Microsoft espera que Don
participe de una serie de proyectos con
miras al futuro.
Antes de unirse a Microsoft, Don fue
Asociado de IBM y Arquitecto Principal para
el Grupo de Software de IBM (SWG). Don
brind liderazgo tcnico absoluto para
WebSphere, Tivoli, DB2, Rational y Lotus.
Tambin presidi el SWG Architecture Board (SWG AB). El SWG AB se
centraba en la integracin de productos, iniciativas de producto
cruzado y tecnologas emergentes. Algunas de las reas de inters
general eran los servicios de Web, patrones, Web 2.0 y el desarrollo
orientado a negocios. Don dirigi la arquitectura y estrategia de IBM
para los servicios de Web y SOA y ha sido co-autor de varias de las
especificaciones de servicios de Web iniciales.
Tengo cinturn negro en Karate (Kenpo) y quiero mejorar en esto.
Quiero tomar otra disciplina Jujitsu. Me gustara ensear Kenpo. La
realizacin personal debe estar en primer lugar.
En lo que respecta a la realizacin profesional y las cosas que me
entusiasman, imagino un punto en el futuro en el que todos puedan
programar. Esto no se trata tanto de utilizar Fortran y C#, sino, por el
contrario, otra definicin de programar. Parece raro, pero djeme
explicarle:
Toda persona que ha terminado la escuela secundaria ha hecho algo
de programacin incluso algo simple como un sitio de Web PHP. stas
son habilidades bsicas en la actualidad simplemente del mismo modo
que aprend a hacer una gran cuenta de dividir a mano (si bien podra
debatir que los estudiantes de hoy en da ya no pueden hacer ms
grandes cuentas de dividir a mano). Estos programadores ocasionales
sern parte de los trabajadores.
Tal vez necesitemos ampliar nuestra definicin de programar.
Cul es la herramienta de programacin principal para los
profesionales de negocios? PowerPoint. Si los profesionales de negocios
pueden utilizar PowerPoint, yo me pregunto si podramos estimularlos
para que utilicen otra herramienta para disear modelos de negocios.
Ellos ya disean modelos de negocio, pero lo hacen utilizando
documentos que se pasan a los programadores. Los programadores
adivinan lo que significan los documentos y no suceden buenas cosas
cuando los programadores adivinan. Me pregunto si podramos hacer
algo ms inteligente. En las escuelas de negocios ensean una
disciplina denominada Ingls estructurado y varias tcnicas de
diagramacin. Tal vez esto podra formar la base para los servicios
comerciales de programacin.
Para m, la realizacin profesional sera analizar el modo en el que
podemos cambiar la naturaleza fundamental de la Web. Web 2.0, las
aplicaciones de Web hbridas y los alimentadores son interesantes,
pero son procesos de uno o dos pasos. La Web de la actualidad es
modelo push. Las personas escriben contenido que es transferido a las
personas que lo leen. Los programadores confeccionan aplicaciones de
Web que utilizan los usuarios finales.
Las personas confeccionan aplicaciones de Web hbridas o secuencias
de comandos para acceder al contenido transferido. Estas
aplicaciones se ejecutan en la actualidad en una PC, pero creo que
podran migrar dentro de Internet. Internet llega a ser un Internet
programable y puede ejecutar las aplicaciones por m. La consigna es
Internet es la computadora. Ya vemos esto en lugares emergentes
con Google, Amazon, MSN, etc. Todos los que ahora poseen servicios
que se pueden llamar. Junto con una gran variedad de habilidades de
programacin, veo un acercamiento entre el entorno comercial y el
personal. Esto es realmente lo que me interesa.
25
Resolver el dilema de la
integracin
Por Jim Wilt
Sntesis
Paquetes basados en estructuras extensibles. Estn por
todos lados. Desde portales hasta comercio electrnico.
Desde administracin de contenido hasta mensajera. Son
eficaces? En varios casos, s, absolutamente. Pienso en
varias aplicaciones exitosas que constru sobre la base de las
estructuras que brindan estos productos. Incentivan la
productividad, aumentan la calidad, mejoran las
caractersticas y reduce en gran medida el tiempo de llegada
al mercado.
Por lo tanto, Por qu las soluciones de integracin no
experimentan las mismas mejoras? Independientemente del
modo en el que trate de formular una solucin de integracin
con una estructura o herramienta determinada, parece que
no avanza al mismo ritmo que experiment con mi solucin
de portal o aplicacin de Web. Esto es lo que defino como
Dilema de Integracin.
s. Esto es causa de mucha frustracin tanto para los equipos de

desarrollo como para la administracin, al igual que la dedicacin del
noventa por ciento, por lo general, no se aplica de ningn modo al
problema de integracin real en cuestin. Esto se magnifica, como
veremos en las prximas secciones, en la medida en que el
problema de integracin en s es generalmente ms difcil que lo
previsto, requiriendo mucho ms tiempo para resolverlo que lo que
permite el diez por ciento restante.
La integracin en estructuras como Microsoft Biztalk Server es
como jugar al bowling con topes en la canaletas. Sus interfaces por
lo general evitan que se daen demasiado sus soluciones, guindolo
con interfaces de implementacin y un diseo rico en caractersticas.
A diferencia de los desafos de seguridad e infraestructura, esta
herramienta realmente ayudar a dirigir la solucin. Sin embargo,
esta experiencia de integracin positiva constituye slo el diez por
ciento del esfuerzo realizado.
Por naturaleza, la integracin en s y por s misma es un problema

difcil de resolver. Examinaremos los factores que contribuyen para
que puedan ser:
Mantenga una relacin laboral cercana con sus equipos operativos
Reconocida y categorizada
Comprendida con las repercusiones resultantes
Tratada proactivamente
La regla del 90/10
El 90 por ciento de la actividad centrada en soluciones de integracin
es de preparacin, configuracin y optimizacin adecuada del entorno
de infraestructura y debida seguridad. Los Sistemas Operativos,
Servicios de Web, Directorios y Configuracin de las Propiedades de la
Aplicacin, as como tambin los Grupos de Aplicaciones, usuario de
procesos de host, Inicio de Sesin nico, Permisos de Directorio,
Seguridad, etc., todos desempean una funcin en la ejecucin y
contribuyen a la frustracin, generalmente asociada con la
implementacin de la integracin.
Varios desarrolladores de paquetes extensibles y aplicaciones se
protegen de tener que preocuparse sobre claves con nombre seguro,
el GAC, certificados, encriptacin, hosts en proceso vs. procesos de
host aislados y otros tantos factores en los que un desarrollador de
integracin debe adquirir mucho dominio y experiencia profesional. El
beneficio es que la experiencia de desarrollo de integracin mejorar
en gran medida el enfoque del desarrollador progresando con
soluciones de aplicacin futuras [normales]. Es decir, las habilidades
del desarrollador se afianzan al finalizar una solucin de integracin.
El 10 por ciento restante, en la regla del 90/10, queda para que el
desarrollador de la integracin resuelva el problema de integracin en
26
Resolver la Regla del 90/10

Sus equipos operativos y de infraestructura son sus nuevos mejores
amigos:
y de infraestructura desde el comienzo del proyecto ya que ellos

pueden identificar anticipadamente potenciales problemas
operativos y de seguridad.
Varios de los problemas agobiantes que encuentran los
desarrolladores de integracin son habituales para un recurso de
infraestructura, por eso, utilice su experiencia para agilizar la
identificacin y resolucin del problema.
EL DESARROLLO DE INTEGRACIN, POR LO

GENERAL, POSEE TOLERANCIA CERO: UNO REPITE
HASTA LOGRAR LA PERFECCIN. LAS FASES Y LA
FUNCIONALIDAD PARCIAL, CON FRECUENCIA, NO
SON UNA OPCIN. POR LO TANTO, LA INTEGRACIN
LLEGA A SER EL ORIGEN DE DEMORA DE VARIOS
PROYECTOS Y EXCESOS DE PRESUPUESTO.
Haga que su entorno de desarrollo imite a su entorno de produccin:
Duplique su LDAP/Active Directory e instale aplicaciones,
servidores y paquetes utilizando el mismo modelo de seguridad

que el de produccin (o lo ms parecido posible).
Nunca desarrolle o ejecute sus soluciones como administrador.
Cuando deba hacer un cambio al entorno durante el desarrollo,
analice el cambio con su equipo operativo/de infraestructura y
documente la modificacin en su documentacin de utilizacin.

El mejor lugar de partida para resolver problemas de infraestructura
de integracin es la seguridad a travs de permisos y accesibilidad.
A para B vs. A para C
Las soluciones de integracin, por lo general, comprenden diversos
contextos de sistemas. Es bueno comprender los dos tipos principales
de problemas de integracin, cmo se resuelven y su complejidad
relativa.
Problemas de A para B: Una casa, dos sistemas
Las caractersticas de los problemas A para B se dan cuando un
Sistema B desea comunicarse con un Sistema A. Por lo general, estn
en la misma infraestructura, pero no estn limitados a sta (pueden
incluir un WAN, VAN, Internet).
Figura 1: Problema de A para B: Dos sistemas, una casa
Sistema
distribuido B
deben realizar esto mediante un intermediario externo, comn o norma

de la industria formato B. Las ubicaciones, por lo general, estn en
infraestructuras separadas (Figura 2).
Un ejemplo de esta situacin comn se da cuando los socios
comerciales utilizan un formato comercial comn XCBL, HIPAA o ANSI
X.12 para comunicarse entre ellos, a veces, mediante un VPN. Con
frecuencia, el esquema intermediario es de 10 a 100 veces ms grande
que el esquema interno que utiliza el Sistema A o C. Estos esquemas
intermediarios pueden ser de 1-2MB, lo que da como resultado
problemas de estabilidad y rendimiento cuando se incorporan a
herramientas de estructuras de integracin empaquetadas en
especial, es frustrante cuando el promedio de la carga til de mensajes
es slo de 20K (Figura 3).
Aparte de estos problemas ms tcnicos, es posible que los dos
socios comerciales deban realizar conjeturas para decidir el lugar en el
formato intermediario B en el que debe colocar su informacin y en
qu lugar su socio comercial ubicar la suya. Adems del hecho de que
un formato intermediario, por lo general, contiene duplicaciones que
normalmente producen ms confusin respecto de la ubicacin
apropiada de la informacin, estas imprecisiones pueden dar lugar a
que se cuestione el valor en esta forma de integracin (por supuesto,
existe valor, pero a veces puede parecer cuestionable).
Esto factores tienden a causar que los problemas de A para C sean
mucho ms difciles de resolver, requiriendo una comunicacin mucho
mayor entre los socios comerciales para resolver las diferencias de
interpretacin con el formato intermediario B.
Solucionar los problemas de A para B y A para C
Documentar claramente sus expectativas para el formato
Sistema
legado A
intermediario B, proporcionando ejemplos.
Reducir el tamao del formato intermediario B mediante el trabajo
Por ejemplo, el Sistema B podra ser un sistema distribuido que

accede a informacin almacenada en el Sistema A, un sistema legado
(Figura 1). El mapeo directo de informacin desde A hacia B requiere
conocimiento detallado de A y de B, pero debido a que el
conocimiento del dominio de los dos sistemas, por lo general, est
disponible dentro de la compaa, existen menos conjeturas sobre
qu elementos y campos de datos en A se relacionan con B.
Problemas de A para C: Mltiples casas, mltiples sistemas
Un problema de A para C describe contextos en los que el socio
comercial A desea comunicarse con el socio comercial C, pero ambos
Figura 2: Problema de A para C: Dos sistemas, dos casas
en conjunto con los socios comerciales para acordar un esquema de

subconjuntos que incluya slo aquellos componentes que utilizan
todos los socios comerciales.
Duplicar o triplicar las proyecciones de prueba de los socios
comerciales para compensar las interpretaciones errneas del
formato intermediario B.
Mapeo en el pozo de la desesperacin

Varias soluciones de integracin en s mismas poseen un crecimiento
constante que nunca se planea pero que aumenta la desesperacin a
partir de los excesos de tiempo en la administracin del presupuesto.
Esto se conoce mapeo en el pozo de la desesperacin.
Una vez que se han resuelto todos los problemas de entornos
operativos, infraestructura y seguridad al punto en el que los datos en
s se mueves desde el punto A hacia el punto B (o C), las
interpretaciones de los cientos de miles de campos desde un esquema
al prximo se vuelven el punto central principal. Muy frecuentemente,
los datos requeridos por un punto no son fciles de conseguir en otro, o
el significado previsto para un campo se utiliza para algo
completamente diferente. Los peores problemas imprevistos, por lo
general, aparecen en la fase del mapeo.
Figura 3: Los escenarios de A para C por lo general comprenden un

formato intermediario B
Sistema
legado A
Sistema
distribuido C
VAN
Formato cannico B
Formato estndar de la industria
(ANSI, XCBL, HIPAA, HL7, etc.)
A mapea hacia
el formato
intermediario B
C mapea desde
el formato
intermediario B
Formato
intermediario B
por lo general inflado,
demasiado
redundante
27

Los siguientes ejemplos ilustran el modo en el que esto puede
suceder:
Producir o evaluar informacin que simplemente no existe en ningn

depsito de datos interno.
Campos mal utilizados en depsitos de datos

El socio comercial A debe proporcionar datos de identidad para el
esquema B en el formato que se muestra en la Tabla 1.
Lo suficientemente simple, pero el socio comercial A utiliza con
creatividad el campo de la Inicial del Segundo Nombre para
almacenar aos de datos de servicio, en el que 0-9 representa la
cantidad de aos y A representa 10 aos o ms. Cuando se utiliza la
Inicial del Segundo Nombre mediante una identidad, el socio
Tabla 1: Formato de los datos de identidad

Primer nombre
Char*
Inicial del segundo nombre
Char 1
Apellido
Char*
comercial A simplemente la coloca como parte del primer nombre. La

Tabla 2 representa la forma en la que el socio comercial A puede
almacenar los datos.
Esto ya no es tan simple, verdad?
El socio comercial A debe analizar el campo Primer Nombre para
determinar si la inicial del segundo nombre existe.
El algoritmo de anlisis debe distinguir entre un primer nombre de
dos palabras, Tory Ann, y una inicial real del segundo nombre,
Mary A.
Un anlisis incorrecto puede dar como resultado la confusin entre
Mary A. Anderson con 2 aos de servicio y Mary Anderson con 10
ms aos de servicio.
Una mala eleccin del campo para almacenar aos de datos de
servicio (probablemente, una decisin tomada muchos aos antes
de tener la intencin de compartir estos datos) simplemente
duplica o triplica el tiempo de mapeo desde el esquema del socio
comercial A hacia el esquema del socio comercial B.
Interrupcin del trabajo de otros miembros del equipo sobre otras

partes de la solucin cuando se interrumpe un mapeo.
Los mapeos del mundo real tienen una apariencia ms parecida a la

Figura 5. Las novedades significativas para herramientas de mapeo en
el mundo real, como el nuevo XSLT Mapper de BizTalk, han sido
demostradas y se ofrecen para mitigar esta tarea tediosa, pero el
desafo va ms all de lo que cualquier herramienta determinada est
en condiciones de realizar (Ver Recursos).
Repeticiones interminables
En el desarrollo normal de las aplicaciones, las repeticiones son algo
bueno. Con frecuencia, se puede determinar la cantidad de iteraciones
que sern permitidas o decidir sobre una tolerancia a la funcin/forma
aceptable que desencadenar los prximos pasos. Por lo general, la
funcionalidad parcial es aceptable y se pueden utilizar fases para
incorporar posteriormente la funcionalidad que falta.
Sin embargo, el desarrollo de integracin, por lo general, posee
tolerancia cero: uno repite hasta lograr la perfeccin. Las fases y la
funcionalidad parcial, con frecuencia, no son una opcin. Por lo tanto,
la integracin llega a ser el origen de demora de varios proyectos y
excesos de presupuesto.
Figura 4: Demo del mapeo de software de integracin
Mapeo del mundo real

Cuando los proveedores de software de integracin demuestran el
mapeo, por lo general, tiene una presentacin parecida a la de la
Figura 4.
Solucionar el mapeo en el pozo de la desesperacin
El mapeo del mundo real es un problema muy diferente que

comprende:
No realice suposiciones sobre la dificultad para mapear; siempre
Cientos de miles de campos.

Diferencias jerrquicas en los formatos de los campos que pueden
requerir algoritmos de ejecucin de bucles complicados para

colocar los datos de forma adecuada.
Grandes flujos de datos que requieren bucles complicados para
dividir los mensajes.
Las herramientas de integracin extravagantes a veces llevan a los
desarrolladores a aplicar una solucin grfica para un problema
que es mucho ms complicado para esta herramienta.
Extraer datos desde mltiples fuentes internas (a veces, de un
modo asncrono).
Tabla 2: Tabla de datos almacenada por el socio comercial A
Nombre
John
Tory Ann
Mary A
Mary
28
Inicial del segundo nombre

5
8
2
A
Apellido
Smith
Wilson
Anderson
Anderson
investigue completamente las fuentes para identificar aquellos

problemas ocultos imprevistos.
Establezca un contrato para pruebas/depuracin con los socios
comerciales especificando la frecuencia de pruebas y proporcione un
criterio de aceptacin con rutas de escalacin adecuadas. En
especial, cuando trabaja con socios comerciales externos, es
imprescindible establecer y definir contratos de pruebas con rutas de
escalacin adecuadas para que cuando ocurran interrupciones en
procedimientos de prueba necesarios (que con toda seguridad
ocurrirn), todas las personas afectadas sean notificadas lo antes
posible para comunicar de forma adecuada las demoras potenciales
en la entrega de la solucin.
Utilice las mejores prcticas de Desarrollo guiado por pruebas para
poder defender y probar completamente su lado de la integracin y
reducir/prevenir el tiempo fuera de servicio para otros miembros del
equipo.
Para mapeos complicados, considere el uso de cdigo y secuencias
de comandos sobre paradigmas de interfaz de usuario extravagantes
(ms fciles de leer y depurar).
Divida los mensajes antes de realizar el mapeo.
Utilice cdigo administrado en vez de mapeos, cuando sea necesario
(por ejemplo, para jerarquas complicadas y un mejor desempeo).
Esto se logra con el uso de clases serializadas.

Trate sus herramientas de integracin del mismo modo. No
todas las soluciones necesitan una Orquestacin. Existen
consecuencias de rendimiento cuando se utiliza una
Orquestacin. Los mapas se pueden utilizar en Puertos as
como tambin en Orquestaciones. A veces, es bueno
experimentar la implementacin de varios prototipos de
soluciones utilizando varias combinaciones del conjunto de
herramientas para comprender las diferencias de rendimiento,
mantenimiento y utilizacin.
Figura 5: Mapeo de datos del mundo real
Conozca sus herramientas y utilice slo las necesarias

(BizTalk)
Haga mejor uso de los modelos de suscripcin/publicacin
basados en Puertos; ya que no existe la Orquestacin, este
modelo, por lo general, no se tiene en cuenta.
Las Orquestaciones son ms eficaces para los flujos de
trabajo; a pesar de que poseen una sobrecarga. Las
Orquestaciones poseen un gran propsito y son muy eficaces
cuando se utilizan para los flujos de trabajo.
Realice mapeos dentro de Puertos, no simplemente
orquestaciones; sta es otra capacidad que se pasa mucho
por alto.
Los pipelines pueden ser rpidos y efectivos, considere un
Pipeline Component personalizado en vez de una
orquestacin reduce las entradas y salidas del buzn de
mensajes y elimina la sobrecarga de la orquestacin.
Las clases serializadas y el cdigo administrado son con
frecuencia una alternativa eficaz para los mensajes y mapas.
Comprenda y respete los criterios de ejecucin relacionados con el

mapeo (por ejemplo, debido a que los mapas son secuencias de
comandos XSLT, nunca utilice cdigo administrado desde un
mapa).
El rendimiento importa
El rendimiento siempre es importante, en especial cuando se dice que
no importa.
Solucionar asuntos de rendimiento (BizTalk)
Reduzca las entradas y salidas del Buzn de Mensajes.
Disminuya la dependencia sobre la orquestacin lo que puede
causar que su solucin se ejecute de un modo mucho ms lento.
El desarrollo orientado al rendimiento implica mtricas de medicin
durante todas las etapas del desarrollo para identificar los
obstculos lo antes posible.
Utilice instrucciones de optimizacin del rendimiento del producto
se han publicado algunas instrucciones excelentes sobre BizTalk
(Ver Recursos).
Listo para usar no est optimizada para su solucin. Existen
varias posibilidades para adaptar el rendimiento, por lo tanto es
importante comprender todos los componentes de la solucin y
optimizarlos de forma adecuada para lograr una operacin ptima.
Las clases serializadas y el cdigo administrado pueden ser ms
rpidos que los mensajes y los mapas, considere su uso para
componentes fundamentales de rendimiento en la solucin.
Considere sus herramientas como un grupo de Legos
Una vez que un equipo adopta un conjunto de herramientas o
paquete para ayudar en la implementacin de sus soluciones de
integracin, un error comn es utilizar cada herramienta del conjunto
para cada solucin de integracin.
En la mayora de los casos, no es necesario utilizar todas las
herramientas. De hecho, utilizar todas las herramientas puede afectar
negativamente el rendimiento de la solucin general.
Una mejor prctica es considerar su conjunto de herramientas
como un grupo de Legos. Los Legos vienen en varios tamaos y
colores. No es necesario utilizar todos los tamaos y todos los colores
en las creaciones. A veces puede querer utilizar slo Legos blancos y
verdes, mientras que otras veces puede centrarse en el azul y el rojo.
Todo depende de resultado que se desee.
Conclusiones
Piense que sus herramientas de integracin son una Ferrari (con
cambios manuales) en su garaje. Al menos que slo pueda manejar
una con cambios automticos, esta Ferrari ser el vehculo ms lento y
frustrante que jams haya conocido. Sin embargo, una vez que logre
dominar los cambios manuales, demostrar por s mismo que
verdaderamente es un auto de carreras de alto rendimiento, calibrado
con precisin.
Las herramientas adecuadas junto con las prcticas y habilidades
correctas pueden con toda seguridad resolver el dilema de la
integracin.
Recursos
Eddie Churchill, BizTalks sexy new XSLT Mapper
http://channel9.msdn.com/Showpost.aspx?postid=126990
BizTalk guidelines
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
bts_2004wp/html/87f447a2-09ce-4a30-9f94-584684310051.asp
Sobre el autor
Jim Kilt dedic su experiencia y capacidad a resolver problemas con el
objeto de ayudar a los clientes a disear las mejores soluciones
posibles para que tengan xito en sus necesidades relacionadas con el
diseo de sistemas, colaboracin, datos, integracin e inteligencia
comercial. Es arquitecto de soluciones con credencial MCA de Microsoft
y ha recibido varios premios de la industria, incluyendo 1993 Industry
Week Technology of the Year Award y Burroughs Achievement Award
for Excellence. Tambin es Microsoft Most Valuabe Professional Visual
Developer Solutions Architect, miembro del Microsoft MCA Board of
Directors, la Central Michigan University Collage of Science and
Technology Alumni Advisory Board y es Central Michigan University
Distinguished Alumni.
29
Ontologa y Taxonoma de
los Servicios en una
Arquitectura Orientada a
Servicios
Por Shy Cohen
Sntesis
Este artculo describe una ontologa y taxonoma para los
servicios de una Arquitectura Orientada a Servicios (SOA);
analiza la naturaleza y las interrelaciones de los diferentes
tipos de servicio, describe un diseo genrico para los
sistemas basados en SOA y proporciona orientacin sobre la
construccin y administracin de los servicios. La ontologa y
taxonoma que se describe aqu brinda un lenguaje comn
para arquitectos, ingenieros y personas responsables de la
toma de decisiones y facilita la comunicacin dentro y entre
las diferentes disciplinas y organizaciones.
Taxonoma de Servicios
Las economas orientadas a servicios prosperan mediante la
promocin de la composicin. En SOA, se pueden crear nuevas
soluciones mediante la composicin de nueva funcionalidad y lgica
de negocios de aplicacin especfica, con capacidades comerciales
existentes, recombinantes. En la actualidad, estas capacidades
comerciales se construyen en su mayora de un modo interno o se
compran para implementarlas en el sitio como una solucin
empaquetada. Sin analizamos el futuro cercano, observamos un
crecimiento constante en el modelo de Software como Servicio
(SaaS) como una opcin para brindar a las organizaciones la
posibilidad de contratar soluciones componentizadas y capacidades
comerciales, enriqueciendo de este modo el conjunto de componentes
que pueden ser incluidos en las aplicaciones compuestas de la
organizacin.
Una ontologa es un modelo de datos que representa un conjunto
de conceptos dentro de un dominio y las relaciones entre esos
conceptos. Una taxonoma es una clasificacin de las cosas as como
tambin de los principios subyacentes de esa clasificacin. Una
taxonoma jerrquica es una estructura en forma de rbol de las
clasificaciones de un grupo de objetos determinados. Este artculo
define las categoras de servicios en SOA, las relaciones entre esas
categoras y los principios que subyacen la clasificacin de diferentes
tipos de servicio dentro de distintas categoras. Adems de definir,
clasificar y proporcionar los principios de clasificacin, trata la
arquitectura de software y los aspectos relacionados con la empresa
relevantes para la construccin y administracin de aplicaciones
compuestas en SOA.
Si analizamos la composicin desde un punto de vista de
arquitectura de software, una ontologa y taxonoma comn nos
permite identificar las caractersticas comunes de los servicios que
constituyen una categora particular. Estas caractersticas afectan la
arquitectura y el diseo de soluciones basadas en SOA desde el nivel
de servicio individual hasta la aplicacin compuesta completa. La
categorizacin soporta la composicin mediante la aclaracin de roles
de los distintos componentes, ayudando de este modo a analizar las
relaciones entre los componentes. La categorizacin tambin
contribuye con la deteccin de servicios (por ejemplo, bsqueda de
30
servicios existentes mediante el uso de un repositorio de servicios)

que adems pueden promover la reutilizacin.
Si analizamos la composicin desde el punto de vista comercial,
una ontologa y taxonoma comn apropiada puede ayudar en la
toma de decisiones relacionadas con el negocio, por ejemplo, cmo
obtener una capacidad (Construir vs. Comprar vs. Contratar),
cmo administrar servicios (administracin central vs. por
aplicacin) y dems.
Categoras y tipos de servicios
En la medida que examinamos los tipos de servicios observamos dos
tipos principales: aquellos que son infraestructurales por naturaleza
y proporcionan prestaciones comunes que no se consideraran parte
de la aplicacin, y aquellos que son parte de la aplicacin y proveen
los bloques de construccin de la aplicacin.
Las aplicaciones de software utilizan una variedad de prestaciones
comunes que van desde servicios de bajo nivel ofrecidos por el
sistema operativo, como administracin de memoria y manejo de
I/O, hasta servicios especficos de entorno de tiempo de ejecucin de
alto nivel, como la Biblioteca en Tiempo de Ejecucin (RTL), la
plataforma Java o la estructura .NET. Las soluciones que se
construyen utilizando un SOA, tambin usan prestaciones comunes,
como una estructura para la creacin de servicios (por ejemplo,
Windows Communication Foundation de Microsoft) y un conjunto de
servicios que son parte de la infraestructura informtica distribuida
de soporte. Llamaremos a este conjunto de servicios Bus de
Servicios (a veces, tambin se los denomina servicios de
infraestructura).
El Bus de Servicios adems se divide en Servicios de
Comunicacin, que brindan la posibilidad de transferir mensajes
como publicacin-suscripcin y enrutamiento de mensajes, y
Servicios de Utilidad, que proporcionan capacidades no
relacionadas con la transferencia de mensajes como deteccin de
servicios y federacin de la identidad.
La eficacia del desarrollo de aplicaciones de software aumenta an
ms mediante la utilizacin de bloques de construccin de alto nivel,
de aplicacin general. Los entornos de programacin RAD que
surgieron repentinamente en la era orientada al componente (como
Delphi de Borland o Visual Basic de Microsoft) brindaban la
posibilidad de componer fcil y rpidamente la funcionalidad y
capacidades provistas por los bloques de construccin existentes con
cdigo de aplicacin especfico para crear nuevas aplicaciones.
Ejemplos de estos componentes abarcan desde las abstracciones de
acceso a bases de datos y estructuras GUI ms genricas hasta los
servicios ms especficos, como por ejemplo el registro de eventos o
grficos. Las aplicaciones compuestas en SOA tambin utilizan
bloques de construccin de esta naturaleza en su modelo de
composicin. Llamaremos a estos bloques de construccin Servicios
de Aplicacin.
Los Servicios de Aplicacin se dividen en Servicios de Entidad,
que exponen y permiten la manipulacin de entidades de negocios;
Servicios de Capacidad y Servicios de Actividad, que
implementan los bloques de construccin funcionales de la aplicacin
(a veces, denominados componentes o mdulos); y Servicios de
Categoras de servicios en SOA

Proceso, que componen y organizan la entidad, capacidad y
Servicios de Actividad para implementar procesos de negocio.
La Figura 1 exhibe una muestra de la composicin de servicios en
las categoras de servicio para la implementacin de un proceso de
negocio. En este contexto a modo de ejemplo, se muestra que un
Servicio de Proceso organiza tres Servicios de Actividad y dos
Servicios de Capacidad. Es bastante normal para los Servicios de
Proceso asociar otros varios servicios para implementar un proceso
de negocio complejo. En el diagrama, uno de los Servicios de
Actividad (Actividad 2) utiliza un Servicio de Capacidad (Capacidad 3)
como lo indica la lnea que los conecta. Un motivo posible para esto
es que la Actividad 2 puede estar implementando una actividad de
pasos mltiples sobre el Servicio de Capacidad, o exponiendo una
interfaz de servicio diferente a la del Servicio de Capacidad
subyacente. Los Servicios de Capacidad 2 y 3 se implementan sobre
los Servicios de Entidad 2 y 3 (respectivamente). Es interesante
observar que los Servicios de Entidad 2 y 3 estn accediendo al
mismo almacn de datos subyacente. Esto puede darse para exponer
diferentes entidades desde un almacn subyacente o para exponer la
misma entidad de diferentes formas para que se adhieran a los
distintos requisitos que poseen los Servicios de Capacidad 2 y 3 con
respecto al modelo de datos. En este contexto a modo de ejemplo,
tambin podemos ver que la Capacidad 1 se encuentra fuera del
entorno organizacional (como lo indica la nube de Internet), y acta
como un recurso interno que est integrado dentro del proceso de
negocio que se implementa mediante el Servicio de Proceso.
atrs y hacia adelante a travs de una barrera de red (es decir,

vinculando dos redes de algn modo desconectadas) o a travs de una
barrera de protocolo (como trasladar mensajes en cola entre el sistema
de cola WebSphere MQ de IBM y el sistema de cola MSMQ de
Microsoft). Los ejemplos de Servicios de Comunicacin incluyen
retransmisiones/puentes/enrutadores/puertas de enlace, servicios de
publicacin-suscripcin y colas.
Los Servicios de Comunicacin no contienen ningn estado de la
aplicacin, pero en algunos casos estn configurados para trabajar en
conjunto con las aplicaciones que los utilizan. Una aplicacin particular
puede necesitar establecer o configurar un Servicio de Comunicacin
respecto del modo de transmisin de los mensajes que circulan dentro
de esa aplicacin, de manera tal que, la comunicacin entre los
componentes sea posible en una arquitectura de estructura flexible. Por
ejemplo, un enrutador basado en el contenido puede necesitar que la
aplicacin proporcione instrucciones de enrutamiento de modo que el
enrutador conozca el lugar al que debe enviar un mensaje. Otro
ejemplo podra ser un servicio de publicacin-suscripcin que debe
enviar mensajes a los suscriptores registrados basndose en un filtro
que puede aplicarse al contenido del mensaje. Este filtro deber ser
establecido por la aplicacin. En ambos casos, el Servicio de
Comunicacin no procesa el contenido del mensaje sino que
(opcionalmente) utiliza partes de ste, del modo establecido por la
aplicacin, para determinar la ubicacin a la que debe ir.
Adems de los requisitos especficos de la aplicacin, las
restricciones que impone la seguridad, las normativas y otras fuentes
de limitacin, pueden dictar que, para utilizar las prestaciones que
Bus de Servicios
ofrece un Servicio de Comunicacin particular, los usuarios debern
Los Buses de Servicios son prestaciones comunes que no aportan
procesar ciertos permisos. Estos permisos pueden establecerse en el
ningn valor comercial explcito, sino que ms bien son parte de la
mbito de la aplicacin (permitiendo que una aplicacin utilice el
infraestructura necesaria para la implementacin de cualquier proceso servicio sin tener en cuenta el usuario que usa la aplicacin), en el
de negocio en SOA. Los Buses de Servicios son componentes que
mbito del usuario (permitiendo que un usuario especfico utilice el
sirven a aplicaciones mltiples, por lo general, construidos de forma
servicio sin tener en cuenta la aplicacin que est usando el usuario) o
central o adquiridos, y en consecuencia, se administran centralmente. en ambos mbitos (permitiendo que un usuario especfico acceda al
servicio mientras ejecuta una aplicacin especfica). Por ejemplo, un
Servicios de Comunicacin
servicio de publicacin-suscripcin puede estar configurado para
Los Servicios de Comunicacin transportan mensajes hacia, fuera de
restringir el acceso a temas especficos, permitiendo que slo se
y dentro de los sistemas, sin tener en cuenta el contenido de los
suscriban usuarios especficos.
mensajes. Por ejemplo, un puente puede trasladar mensajes hacia
Otras prestaciones al nivel de la aplicacin que pueden ofrecer los
Servicios de Comunicacin estn vinculadas
al monitoreo, diagnstico y monitoreo de
las actividades del negocio (BAM). Los
Figura 1: Ejemplo de composicin de servicios en las categoras de servicios
Servicios de Comunicacin pueden
proporcionar informacin esttica sobre la
Servicios de
aplicacin, como un anlisis del patrn de
Proceso
Utilidad
Actividad 1
trfico del mensaje (cantidad de mensajes
Nube de Internet
que circulan a travs de un puente por
Capacidad
Descubrir
minuto), informes de la tasa de error
Actividad 2
(cantidad de errores de SOAP que se
Identificar
envan a travs de un enrutador por da) o
indicadores del rendimiento del nivel del
Actividad 3
Capacidad 2
Capacidad 3
...
negocio (cantidad de rdenes de compra
que ingresan mediante una puerta de
Entidad 1
Entidad 2
Entidad 3
enlace de un socio). Si bien pueden ser
especficas para una aplicacin en
particular, estas capacidades no son
diferentes a las propiedades de
configuracin que se utilizan para controlar
el flujo de mensajes. Habitualmente, esta
informacin es proporcionada mediante
Bus de Servicios
Publicaruna funcin genrica del Servicio de
Enrutamiento
Cola
...
Suscribir
Comunicacin, que generalmente debe ser
31

configurada por la aplicacin. La informacin estadstica que se
proporciona, por lo general, debe ser consumida por una parte
especfica de la aplicacin que sepa lo que hacer con ella (por
ejemplo, activar un alerta de seguridad en el centro de datos o
actualizar un diagrama relacionado con el BAM en la pantalla de la
computadora del CFO). La Tabla 1 resume las caractersticas de los
Servicios de Comunicacin.
Tabla 1: Resumen de la categora de Servicios de Comunicacin
Servicios de comunicacin
Objetivo principal
Transporte de mensajes
Interfaz
No procesa los mensajes de la aplicacin. Puede
tener interfaces de administracin y monitoreo
Administracin del estado
No administra el estado de la aplicacin
Transacciones
No se aplica (porque no procesa mensajes de la
aplicacin)
Manejo de errores
No se manejan errores relacionados con la
aplicacin
Seguridad
Usuario/Aplicacin/Ambos
Gestin/Gobierno
Centralizados
Modo de construccin
Se compra o se construye de modo central
Servicios de Utilidad
Los Servicios de Utilidad proporcionan servicios genricos, de
aplicacin agnstica que tratan aspectos que no estn relacionados
con la transmisin de mensajes de la aplicacin. Al igual que los
Servicios de Comunicacin, la funcionalidad que ofrecen es parte de
la infraestructura base de un SOA y no est relacionada con ningn
proceso de negocio o lgica de la aplicacin especfica. Por ejemplo,
un servicio de deteccin puede ser utilizado por componentes en una
aplicacin compuesta de estructura flexible para detectar otros
componentes de la aplicacin basados en algn criterio particular (por
ejemplo, un servicio que se implementa dentro de un entorno de
preproduccin puede buscar otro servicio que implemente una cierta
interfaz necesaria para el primer servicio y que tambin se
implementa en el entorno de preproduccin). Los ejemplos de
Servicios de Utilidad incluyen Servicios de idEntity y seguridad (por
ejemplo, un Servicio de Identidad Federada o un Servicio de
Credenciales de Seguridad), servicios de deteccin (como un servidor
UDDI) y servicios de transformacin de mensajes.
Al igual que los Servicios de Comunicacin, los Servicios de Utilidad
tambin pueden ser instruidos o configurados por una aplicacin
particular respecto del modo de realizar una operacin en su
representacin. Por ejemplo, un servicio de transformacin de
mensajes puede transformar mensajes desde un esquema de
mensajes hacia otro basndose en un mapeo de trasformacin que
proporciona la aplicacin utilizando el servicio de transformacin de
mensajes.
Si bien los Servicios de Utilidad no contienen ningn estado de la
aplicacin, el estado de un Servicio de Utilidad puede estar afectado
por los cambios de estado del sistema. Por ejemplo, un usuario nuevo
que se agrega a la aplicacin puede requerir una actualizacin de las
opciones de credencial en el Servicio de Credenciales de Seguridad. A
diferencia de los Servicios de Comunicacin, los Servicio de Aplicacin
interactan directamente con los Servicios de Utilidad que procesan
y, si es necesario, responden los mensajes que los Servicios de
Aplicacin les enviaron.
Los usuarios de Servicios de Utilidad pueden requerir la
configuracin de un permiso para utilizar el servicio, ya sea en el
mbito de la aplicacin, del usuario o de la aplicacin-usuario. Por
ejemplo, un servicio de deteccin tal vez slo trabaje con usuarios de
dominio autenticados (usuarios que poseen credenciales vlidas
emitidas por un controlador de dominio de Windows).
Al igual que los Servicios de Comunicacin, los Servicios de Utilidad
pueden brindar prestaciones en el mbito de la aplicacin para el
monitoreo, diagnstico, BAM y dems. Esto puede incluir informacin
estadstica sobre patrones de uso (cantidad de usuarios de otra
32
organizacin que se autenticaron utilizando una identidad federada),

tasa de error que impacta el negocio (cantidad de rdenes de compra o
transformaciones al formato del mensaje que fallaron debido a
mensajes entrantes mal formateados), etc. Como es el caso del los
Servicios de Comunicacin, estas prestaciones, por lo general, son
caractersticas genricas del Servicio de Utilidad y deben ser
configuradas y consumidas por la solucin particular en la que estn
siendo utilizadas. La Tabla 2 resume las caractersticas de los Servicios
de Utilidad.
Servicios de Aplicacin
Los Servicios de Aplicacin son servicios que participan en la
implementacin de un proceso de negocios. Proporcionan un valor
comercial explcito y existen sobre una escala que comienza en un
extremo con servicios genricos que se utilizan en cualquier aplicacin
compuesta de la organizacin y finaliza en el otro extremo con
servicios especializados que son parte de una nica aplicacin
compuesta, y en el medio, posee servicios que pueden ser utilizados
por dos o ms aplicaciones.
Servicios de Entidad
Los Servicios de Entidad descubren y manifiestan las entidades de
negocio en el sistema. Pueden considerarse como componentes
centrados en datos (nombres) del proceso de negocio: empleado,
cliente, orden de venta, etc. Los ejemplos de Servicios de Entidad
incluyen un servicio al cliente que administra la informacin del cliente
o un servicio de rdenes que administra los pedidos del cliente.
Los Servicios de Entidad abstraen almacenes de datos (como SQL
Server o Active Directory) y exponen la informacin almacenada en el
sistema en uno o ms almacenes de datos mediante una interfaz de
servicio. Por lo tanto, se puede decir que los Servicios de Entidad
administran el estado persistente del sistema. En algunos casos, la
informacin que administran trasciende un sistema especfico y es
utilizada en varios, o incluso todos, los sistemas de la organizacin.
Es muy comn que los Servicios de Entidad soporten una interfaz
CRUD (crear, leer, actualizar y eliminar) en el nivel de la entidad, e
incorporan operaciones adicionales especficas de dominio necesarias
para tratar dominios problemticos y soportar los casos de uso y
caractersticas de la aplicacin. Un ejemplo de una operacin especfica
de dominio es un servicio al cliente que expone un mtodo llamado
FindCustomerByLocation que puede localizar el ID del cliente si se
proporciona la direccin del cliente.
La informacin que administran los Servicios de Entidad, por lo
general, existe por un perodo de tiempo que es mayor al de cualquier
proceso de negocio nico. La informacin que exponen los Servicios de
Entidad es normalmente estructurada, a diferencia de los almacenes de
datos jerrquicos o relacionales que son ofrecidos por el servicio. Por
ejemplo, un servicio puede agregar la informacin almacenada en
varias tablas de bases de datos o incluso varias bases de datos
Tabla 2: Resumen de la categora de Servicios de Utilidad

Servicios de Utilidad
Objetivo principal
Interfaz

Transacciones
Manejo de errores
Seguridad
Gestin/Gobierno
Modo de construccin
Funcionalidad infraestructural genrica (no

especfica de la aplicacin)
Interfaz del servicio para exponer la
funcionalidad del servicio. Tambin puede tener
interfaces de administracin y monitoreo
No se administra el estado de la aplicacin.
Puede tener su propio estado.
Por lo general, no poseen soporte
No se manejan errores relacionados con la
aplicacin o se realiza con limitaciones
Centralizados
Normalmente se compran

separadas y proyectar esta informacin como una
entidad nica.
Tabla 3: Resumen de la categora de Servicios de Entidad
En algunos casos, generalmente por
Servicios de entidad
conveniencia, los implementadores del servicio de
Objetivo principal
Exponer y administrar las entidades de negocio
entidad optan por exponer los datos subyacentes
Interfaz
Operaciones especficas de dominio y CRUD en el mbito de la entidad
como conjuntos de datos en vez de datos de XML
Administracin
del
estado
La administracin del estado de la aplicacin es el objetivo principal
muy esquematizados. Si bien los conjuntos de datos
Transacciones
Atmica y/o Patrn de Reserva
no son entidades en el sentido estricto, estos
Manejo de errores
Compensacin del error limitada (Afecta SLE y SLA)
servicios an se consideran Servicios de Entidad por
Seguridad
razones de clasificacin.
Gestin/Gobierno
Centralizados
Los usuarios de Servicios de Entidad pueden
Modo de construccin
Interno/compra/contratacin
necesitar que se les configure un permiso para
utilizar el servicio, ya sea en el mbito del usuario,
de la aplicacin o de la aplicacin-usuario. Estos permisos pueden
realizan mediante tarjeta de crdito, o un bloque de construccin de
aplicar restricciones sobre los cambios y/o acceso a datos en el nivel
valor agregado como un servicio de evaluacin que puede procesar y
de la fila (entidad) o la columna (elemento de la entidad). Un
calcular la evaluacin del usuario respecto de cualquier cosa que pueda
ejemplo de restriccin en el nivel de la columna sera que una
ser evaluada (sin la necesidad de una pgina de ayuda, un libro, un
aplicacin HR pudiera tener acceso a ambos elementos de la entidad
proveedor, etc.) en cualquier aplicacin que utiliza evaluaciones. Los
del empleado, seguridad social y domicilio particular, mientras que un Servicios de Capacidad pueden dividirse an ms por el tipo de servicio
servicio de impresin de cheques slo tendra acceso al elemento de
que brindan (por ejemplo, interfaz de terceros o bloques de
domicilio particular. Un ejemplo de restriccin en el nivel de la fila
construccin de valor agregado), pero esta distincin complementaria
sera una aplicacin de informe de gastos que permite a los gerentes
est fuera del alcance de este anlisis.
ver y aprobar informes de gastos para los empleados que les rinden
Los Servicios de Capacidad exponen una interfaz de servicio
cuentas, pero no para los empleados que no les rinden cuentas.
especfica para la capacidad que representan. En algunos casos, una
La compensacin de error en los Servicios de Entidad, en la
capacidad de negocio recientemente adquirida o existente (legado)
mayora de los casos, est limitada a buscar fuentes alternativas de
puede no cumplir con el modo que posee la organizacin de exponer
datos, si las hubiera. Por ejemplo, si un Servicio de Entidad no puede capacidades como servicios, o incluso, puede no exponer una interfaz
acceder a una base de datos local, puede tratar de obtener una copia de servicio en absoluto. En estos casos, la capacidad normalmente se
remota de la base de datos para conseguir la informacin necesaria.
empaqueta con una capa de servicio ligera que expone el API de la
Para soportar la consistencia del estado del sistema, los Servicios de
capacidad utilizando una interfaz de servicio que se adhiere al modo de
Entidad pueden admitir transacciones atmicas distribuidas
exponer capacidades que tiene la organizacin. Por ejemplo, algunas
estrechamente acopladas. Los servicios que admiten transacciones
empresas que prestan servicios de procesamiento de tarjetas de
atmicas distribuidas participan en transacciones que les circulan los
crdito presentan un API basado en HTML que requiere que el usuario
solicitantes y estn sujetas a cualquier cambio de estado en el
complete un formulario basado en la Web. Una capacidad como sta
almacn de datos subyacente para el resultado de estas
sera empaquetada a travs de una fachada del servicio administrada y
transacciones atmicas distribuidas. Para permitir un grado menor de creada de un modo interno que proporciona un fcil acceso
acoplamiento en el cambio de estado, los Servicios de Entidad pueden programtico a la capacidad. La fachada del servicio es poco clara y
brindar soporte para Patrones de Reserva de estructura ms flexible,
oculta la verdadera naturaleza de la capacidad detrs de ella hasta el
ya sea adems de o en vez de admitir transacciones atmicas
punto en el que la capacidad subyacente puede ser reemplazada sin
distribuidas.
cambiar la interfaz de servicio que se utiliza para accederla. Por lo
Los Servicios de Entidad con frecuencia se construyen de un modo
tanto, se considera que la fachada del servicio es el Servicio de
interno, como un contenedor, sobre una base de datos existente.
Capacidad y la capacidad subyacente es simplemente un detalle de
Estos servicios, por lo general, se implementan mediante la escritura
implementacin de la fachada de servicio.
de cdigo para distribuir registros de las bases de datos hacia
Por lo general, los Servicios de Capacidad no administran
entidades y exponerlos en una interfaz de servicio o mediante el uso
directamente el estado de la aplicacin; para realizar cambios de
de una fbrica de software para generar el cdigo de distribucin y la estado en la aplicacin, utilizan Servicios de Entidad. Si un Servicio de
interfaz de servicio. La Fabrica de Software de Servicios de Web del
Capacidad no administra el estado, normalmente, el estado es
grupo de Prcticas y Patrones de Microsoft es un ejemplo de esta
transitorio y dura por un perodo de tiempo menor que el tiempo
fbrica de software. En algunos casos, la base de datos (por ejemplo, necesario para completar el proceso de negocio en el que participa este
el SQL Server 2005 de Microsoft) o la aplicacin centrada en datos
Servicio de Capacidad. Por ejemplo, un Servicio de Capacidad que
(por ejemplo, SAP) pueden brindar de forma nativa prestaciones que
brinda presupuestos para el envo de productos podra registrar el
permiten el acceso a los datos a travs de una interfaz de servicio,
hecho de que los pedidos de presupuestos fueron enviados a quienes
eliminando la necesidad de generar y mantener un Servicio de
realizan los envos hasta que se devuelva una respuesta, despus de lo
Entidad por separado.
cual se elimina ese registro. Adems, un Servicio de Capacidad que se
Los Servicios de Entidad por lo general se utilizan en ms de una
implementa como un flujo de trabajo podr administrar el estado
aplicacin compuesta y, por lo tanto, habitualmente se administran
transitorio durable de la ejecucin para todas las instancias de ese flujo
de forma central. La Tabla 3 resume las caractersticas de los
de trabajo que se estn ejecutando actualmente. Si bien la mayora de
Servicios de Entidad.
las capacidades son sin estado, existen, por supuesto, capacidades
como registro de eventos que administran y encapsulan el estado por
Servicios de Capacidad
naturaleza.
Los Servicios de Capacidad implementan las capacidades de la
Los usuarios de los Servicios de Capacidad pueden necesitar que se
organizacin en el nivel del negocio y representan los bloques de
les configure un permiso para poder utilizar el servicio, ya sea en el
construccin (accin atmica) centrados en la accin que conforma
nivel de la aplicacin, del usuario o de aplicacin-usuario. El acceso a
los procesos de negocio de la organizacin. Algunos ejemplos de los
un Servicio de Capacidad, por lo general, se concede en el nivel de la
Servicios de Capacidad incluyen servicios de interfaz de terceros,
aplicacin. Los permisos por usuario, habitualmente, son administrados
como un servicio de procesamiento de tarjetas de crdito que se
mediante Servicios de Proceso que utilizan los Servicios de Capacidad
puede utilizar para la comunicacin con una puerta de enlace de pago para simplificar la administracin del acceso y prevenir fallas de acceso
externo en cualquier aplicacin compuesta en la que los pagos se
mientras se realiza el proceso.
33

La compensacin de error en los Servicios de
Capacidad est limitada a cumplir las Expectativas
Tabla 4: Resumen de la categora de Servicios de Capacidad
de Nivel de Servicio (SLE) y los Acuerdos de Nivel
Servicios de capacidad
de Servicio (SLA). Por ejemplo, un servicio de envo
Objetivo principal
Implementar una capacidad de negocios de valor agregado genrica
que normalmente compara los precios y tiempos de
Interfaz
Interfaz del servicio para exponer la funcionalidad principal
entrega de cuatro proveedores (FedEx, UPS, DHL y
Administracin
del
estado
Por lo general no contienen estado especfico de la aplicacin
un servicio de entregas local de la ciudad, por
Transacciones
Al no contener estado no hay necesidad de transacciones. Puede
ejemplo) puede compensar la falta de disponibilidad
implementar el Patrn de Reserva y/o transaccin atmica sobre un
de un proveedor ignorando la falla y continuando
servicio de entidad
con la comparacin de precios que poda obtener,
Manejo de errores
siempre y cuando, recibiera al menos dos
Seguridad
En el nivel de la aplicacin
presupuestos. Este ejemplo demuestra que la
Gestin/Gobierno
Centralizados
Modo de construccin
Interno/compra/contratacin
compensacin puede dar como resultado un
rendimiento ms bajo. Esta degradacin se puede
expresar segn el tiempo de espera, calidad del
Recursos Humanos y acceda la base de datos protegida del
servicio y otros tantos aspectos, y por lo tanto, es necesario
departamento de RH para evaluar la elegibilidad para vacaciones. Un
describirlos en el SLE y el SLA para el servicio.
ejemplo de un Servicio de Actividad que se utiliza para compartir
Los Servicios de Capacidad pueden admitir transacciones atmicas
funcionalidad sera un servicio de morosos que brinda informacin
distribuidas y/o Patrones de Reserva. La mayora de los Servicios de
sobre el estado de mora de un cliente para que esta informacin pueda
Capacidad no administran recursos cuyo estado debe administrarse
ser utilizada por varios Servicios de Proceso dentro de una solucin.
utilizando transacciones atmicas, pero un Servicio de Capacidad
Al igual que los Servicios de Capacidad, los Servicios de Actividad
puede transmitir una transaccin atmica en la que est incluida para
exponen una interfaz de servicio especfica para la capacidad que
los Servicios de Entidad que utiliza. Los Servicios de Capacidad
implementan. Un Servicio de Actividad puede empaquetar una unidad
tambin se usan para implementar un Patrn de Reserva sobre
de funcionalidad existente, en especial, en casos de transicin en los
Servicios de Entidad que no admiten este patrn, y en un grado
que un sistema existente con funcionalidad implementada existente
mucho menor sobre Servicios de Capacidad que no admiten ese
est siendo actualizado para o incluido en una solucin basada en SOA.
patrn.
Del mismo modo que los Servicios de Capacidad, los Servicios de
Los Servicios de Capacidad se pueden desarrollar y administrar de
Actividad, por lo general, no manejan directamente el estado de la
forma interna, se pueden comprar a terceros y administrar de forma
aplicacin; en caso de que lo manejen, ese estado es transitorio y
interna, o se pueden contratar a un proveedor externo y consumir
existe por un perodo de tiempo menor que el tiempo de duracin del
como SaaS que se desarrolla, mantiene y administra de forma
proceso de negocio en el que participa el servicio. Sin embargo, ya que
externa.
Cuando se desarrollan de forma interna, los Servicios de Capacidad su granularidad es un poco mayor y debido a que en algunos casos los
Servicios de Actividad se utilizan para empaquetar un sistema
pueden implementarse utilizando cdigo imperativo o un flujo de
existente, es muy probable que un Servicio de Actividad maneje y
trabajo declarativo. Si se implementan como un flujo de trabajo, un
encapsule el estado de la aplicacin.
Servicio de Capacidad puede ser modelado como una actividad de
Los Usuarios de Servicios de Actividad pueden requerir que se les
negocio de ejecucin breve (atmica, no episdica). Las actividades
configure un permiso para utilizar el servicio, ya sea en el mbito de la
de negocio de larga duracin, en las que las cosas pueden fallar o
aplicacin, del usuario o aplicacin-usuario. Como en el caso de los
necesitar compensacin, por lo general, se incluyen dentro de la
Servicios de Capacidad, el acceso a un Servicio de Actividad
categora del Servicio de Proceso.
Un Servicio de Capacidad es casi siempre utilizado por aplicaciones normalmente se concede en el nivel de la aplicacin y se administra
para cada usuario mediante los Servicios de Proceso que estn
compuestas mltiples y, por lo tanto, es normalmente administrado
utilizando el Servicio de Actividad.
de modo central. La Tabla 4 resume las caractersticas de los
Los Servicios de Actividad poseen las mismas caractersticas para
Servicios de Capacidad.
compensacin de error y soporte de transaccin que los Servicios de
Capacidad. Los Servicios de Actividad normalmente se desarrollan y
Servicios de Actividad
administran de un modo interno y pueden implementarse utilizando
Los Servicios de Actividad implementan las capacidades en el nivel
del negocio o algn otro elemento de lgica de negocio centrado en la cdigo imperativo o un flujo de trabajo declarativo. Como en el caso de
accin (bloques de construccin) que son nicos para una aplicacin un Servicio de Capacidad, si se implementa como un flujo de trabajo,
particular. La diferencia principal entre los Servicios de Actividad y los un Servicio de Actividad puede ser modelado como una actividad de
negocio de ejecucin breve.
Servicios de Capacidad es el mbito en el que se los utiliza. Si bien
Los Servicios de Actividad, por lo general, son utilizados por una
los Servicios de Capacidad son un recurso organizacional, los
solucin o aplicacin nica y por lo tanto, normalmente, se administran
Servicios de Actividad se utilizan en mbitos mucho ms pequeos,
de forma individual, por ejemplo, en el nivel departamental. Si un
como una aplicacin compuesta nica o una solucin nica
Servicio de Actividad evoluciona en un Servicio de Capacidad, la
(compuesta de varias aplicaciones). Con el paso del tiempo y con la
administracin del servicio, habitualmente, pasa a un servicio de
suficiente reutilizacin en la organizacin, un Servicio de Actividad
administracin central. La Tabla 5 resume las caractersticas de los
puede evolucionar en un Servicio de Capacidad.
Servicios de Actividad.
Los Servicios de Actividad normalmente se crean para facilitar la
descomposicin de un proceso complicado o para permitir la
Servicios de Proceso
reutilizacin de una unidad de funcionalidad especfica en diversos
lugares en un Servicio de Proceso particular o incluso entre diferentes Los Servicios de Proceso relacionan los bloques de construccin
centrados en datos y centrados en la accin para implementar los
Servicios de Proceso en la aplicacin. Las fuerzas que impulsan la
procesos de negocio de la organizacin. Estos servicios componen la
creacin de Servicios de Actividad pueden provenir de diversas
funcionalidad que brindan los Servicios de Actividad, Servicios de
fuentes, como fuerzas organizacionales, requisitos de seguridad,
Capacidad y Servicios de Entidad y los relacionan con la lgica de
requisitos normativos y dems. Un ejemplo de un Servicio de
negocio que est dentro del Servicio de Proceso para crear el proyecto
Actividad que se crea en un contexto de descomposicin es un
servicio de confirmacin de elegibilidad para vacaciones que, debido a que define la operacin del negocio. Un ejemplo de Servicios de
Proceso es un servicio de procesamiento de rdenes de compra que
requisitos de seguridad, separa una parte especfica del
recibe una orden de compra, la verifica, controla el servicio de clientes
comportamiento de la aplicacin de autorizacin de las vacaciones
para que esa parte se ejecute detrs del firewall del departamento de morosos para asegurarse de que es un cliente apto, verifica el crdito
34

Los Servicios de Proceso, por lo general, se
desarrollan y se administran de modo interno debido a
que capturan la esencia de valor agregado de la
Servicios de actividad
organizacin, el factor secreto que define el modo en
Objetivo principal
Implementar una capacidad de negocios especfica en el nivel
el que la organizacin realiza sus negocios. Los
de la aplicacin
Servicios de Proceso se disean para posibilitar la
Interfaz
Interfaz del servicio para exponer la funcionalidad principal
agilidad del proceso (es decir, para que se pueda
Por lo general no contienen estado especfico de la aplicacin
actualizar fcilmente) y los procesos que pueden
(A menos que contenga y exponga un sistema existente)
implementar son normalmente episdicos por
Transacciones
Puede soportar transacciones atmicas y/o implementar el
naturaleza (la ejecucin est compuesta de breves
Patrn de Reserva sobre un sistema existente
impulsos de actividades espaciados por largas esperas
Manejo de errores
para que se completen las actividades externas). Por lo
Seguridad
En el nivel de la aplicacin
Gestin/Gobierno
Por aplicacin
tanto, los Servicios de Proceso se implementan de
Modo de construccin
Interno
mejor manera como flujos de trabajo declarativos
utilizando un servidor de flujo de trabajo (como BizTalk
de Microsoft) o una estructura de flujo de trabajo
(como Windows Workflow Foundation de Microsoft).
del cliente con el servicio de verificacin de crditos, incluye la orden
Los Servicios de Proceso, con frecuencia, son utilizados por una
en la lista de rdenes que administra el servicio de rdenes (entidad),
reserva los productos con el servicio de inventario (entidad), asegura aplicacin nica y por lo tanto administrados de forma individual (por
ejemplo, en el nivel departamental). En algunos casos, un proceso de
el pago mediante el servicio de procesamiento de pagos, confirma la
negocio reutilizable puede convertirse en un producto que puede
reserva realizada con el servicio de inventario (entidad), programa el
ofrecerse o consumirse como SaaS. La Tabla 6 resume las
envo con el servicio de envos, notifica al cliente sobre la finalizacin
exitosa de su pedido y la ETA de los productos a travs de un servicio caractersticas de los Servicios de Proceso.
de puerta de enlace de correo electrnico y
finalmente marca la orden como finalizada
Tabla 6: Resumen de la categora de Servicios de Proceso
en la lista de rdenes.
Servicios de proceso
Los Servicios de Proceso pueden estar
Objetivo principal
Implementar un servicio de negocios mediante la orquestacin de otros
compuestos de flujos de trabajo u otros
servicios
Procesos de Servicio pero no pueden ser
Interfaz
Interfaz del servicio dirigida a aplicaciones que enfrentan usuarios
recategorizados como capacidades o
Administra el estado del proceso
Servicios de Actividad debido a su alcance y
Transacciones
No posee soporte para las transacciones atmicas. Puede usar
su naturaleza de larga ejecucin.
transacciones atmicas con los servicios que utiliza. Puede implementar
Ya que los Servicios de Proceso
un Patrn de Reserva
implementan los procesos de negocio de la
Manejo de errores
El manejo de errores se implementa como parte de la lgica de negocios
organizacin, con frecuencia, se los ofrece
Seguridad
Usuario
Gestin/Gobierno
Por aplicacin
con una interfaz de usuario que inicia,
Modo de construccin
Interno
controla y monitorea el proceso. La interfaz
del servicio que exponen estos servicios, normalmente, se orienta
hacia el consumo mediante una aplicacin de usuario final y brinda el Conclusin
nivel de granularidad adecuado requerido para satisfacer los casos de Para el arquitecto, tener una buena comprensin de las diferentes
categoras, ayuda a clasificar los servicios nuevos o existentes, as
uso que implementa el usuario que enfrenta puntos de entrada. El
como tambin a definir la funcionalidad adecuada que se debe incluir
monitoreo del proceso de negocios, a veces, puede requerir una
en un servicio especfico para promover la composicin y la
interfaz de monitoreo separada que exponga informacin BAM. Por
reutilizacin. El proyecto de arquitectura que se define aqu se puede
ejemplo, el servicio de procesamiento de rdenes puede informar la
utilizar para el diseo de nuevos sistemas as como tambin para la
cantidad de rdenes pendientes, en proceso y finalizadas y alguna
refactoracin de sistemas existentes.
informacin estadstica sobre stas (tiempo medio dedicado al
Para las personas que toman decisiones, comprender el valor
procesamiento y a la orden, volumen promedio de la orden, etc.).
comercial de un componente y su nivel de comoditizacin, facilita
Los Servicios de Proceso, por lo general, administran el estado de
tomar decisiones sobre construir vs. comprar vs. contratar y puede
la aplicacin relacionado con un proceso especfico durante la
exponer oportunidades comerciales para hacer que un servicio est
duracin de ese proceso. Por ejemplo, el servicio de procesamiento
disponible para otros.
de rdenes de compra administra el estado de la orden hasta que se
completa. Adems, un Servicio de Proceso mantiene y registra el
paso en curso en el proceso de negocios. Por ejemplo, un Servicio de
Proceso que se implementa como un flujo de trabajo contiene el
estado de ejecucin para todas las instancias del flujo de trabajo que
se estn ejecutando actualmente.
Sobre el autor
Los usuarios del Servicio de Proceso pueden requerir que se les
Shy Cohen es gerente de programa en el grupo de Sistemas
configure un permiso para utilizar el servicio. El acceso a un Servicio
Distribuidos de Microsoft. Shy se uni a Microsoft en 1996 y ha
de proceso, por lo general, se concede en el nivel del usuario.
trabajado sobre diferentes tecnologas en diferentes grupos de la
Los Servicios de Proceso muy rara vez soportan la participacin en
compaa, siempre fiel a su gran pasin por la informtica distribuida.
una transaccin atmica distribuida ya que proporcionan soporte para
En los ltimos cinco aos, Shy ha dedicado su tiempo al diseo de
actividades de negocio de larga ejecucin (transacciones de larga
varios de los aspectos tcnicos y de arquitectura de Windows
ejecucin) en las que la compensacin del error ocurre en el nivel de
Communication Foundation (WCF). En la actualidad, dirige su atencin
la lgica de negocio y la compensacin puede requerir flujos de
hacia diversos aspectos relacionados con la creacin de sistemas
trabajo humano. Los Servicios de Proceso pueden utilizar
distribuidos y brinda orientacin sobre sistemas distribuidos, SOA, WCF
transacciones atmicas distribuidas cuando recurren al servicio que
y Servicios de Web as como tambin tecnologas de flujo de trabajo.
usan. Tambin pueden implementar el patrn de reserva.
Tabla 5: Resumen de la categora de Servicios de Actividad
35
Versionado en SOA
Por Boris Lublinsky
Sntesis
La Arquitectura Orientada al Servicio (SOA) est tomando un
primer plano en la arquitectura empresarial. SOA hace
posible el desarrollo paralelo en varios equipos distintos,
cada uno con su propio programa de mantenimiento y
produccin. En este artculo analizar los enfoques para el
control de versiones de servicios que permiten desarrollar
implementaciones de servicios sin afectar a los consumidores
existentes, logrando que las implementaciones de SOA
posean una estructura ms flexible. La idea bsica del
versionado de servicios es muy simple, pero su
implementacin requiere un control estricto. Expondr
unidades de versionado: enfoques de acceso/implementacin
de versin, consideraciones sobre el ciclo de vida de la
versin del servicio, creacin de una nueva versin y
cambios en el servicio. La creacin de versiones basadas en
el mtodo que se propone aqu permite minimizar el impacto
del versionado y reduce la cantidad de cdigo implementado.
La mensajera semntica para las definiciones de interfaz del
servicio permite que la implementacin del servicio sea ms
flexible para el cambio.
Si hay algo constante en las implementaciones informticas, es el
cambio. Las condiciones comerciales cambian, por consiguiente,
requieren que las implementaciones informticas cambien. Las
nuevas tcnicas y patrones permiten una mejor implementacin de
las cualidades del servicio, como sistema de fallas y balanceo de
carga, seguridad y dems. La informtica en s misma cambia
continuamente con la presentacin de nuevos sistemas operativos,
lenguajes de programacin y servidores de aplicacin, por ejemplo,
que simplifican la creacin y mantenimiento de nuevas soluciones. De
hecho, un estmulo en la implementacin de una solucin de
informtica es la capacidad de hacer frente a estos cambios
inevitables.
En la era de aplicaciones monolticas, los cambios se trataban
sobre la base de aplicacin-por-aplicacin. La implementacin del
cambio, ya sea para un nuevo negocio o infraestructura por
ejemplo, la incorporacin de un requisito o poltica de seguridad, o
trasladar una aplicacin a una nueva plataforma de software se
realizaba para una aplicacin completa, consumiendo importantes
cantidades de tiempo y dinero hasta su finalizacin. Por otro lado,
debido a que cada aplicacin era desarrollada por un nico equipo e
independiente, este enfoque no permita los cambios. En la medida
que se presentaban nuevas versiones de una aplicacin, la versin
anterior quedaba en desuso y poda eliminarse.
Uno de los beneficios principales del estilo de arquitectura
orientada a servicios es la capacidad de tratar los cambios de un
modo eficaz. SOA est basada en la descomposicin de recursos
informticos de la empresa y la separacin de artefactos informticos
36
estables (servicios) desde artefactos modificables (procesos de

negocio) que organizan los servicios hasta soluciones informticas
(procesos). Como consecuencia, por lo general, es posible cumplir
con los cambios de requisitos comerciales, ya sea mediante cambios
en los procesos existentes o la creacin de nuevos procesos de
negocio empresariales basados en los servicios existentes. Este
enfoque permite un mejor soporte (ms rpido y econmico) de los
cambios requeridos a travs de la (re)composicin de una solucin
basada en los servicios empresariales reutilizables. Los servicios
empresariales ser convierten en recursos, que pueden ser
compartidos por mltiples soluciones empresariales, permitiendo el
desarrollo autnomo paralelo masivo a varios equipos diferentes,
cada uno con su propio programa de mantenimiento y produccin.
Debido a que cada servicio, en este caso, es utilizado de forma
simultnea en varias soluciones empresariales, un cambio en un
servicio empresarial puede tener un impacto significativo sobre
varias implementaciones existentes y en consecuencia, puede
requerir cambios en cada una de ellas. Esto no slo es
extremadamente costoso (requiere una gran coordinacin entre los
equipos de desarrollo y las pruebas para garantizar que ninguno de
los mltiples consumidores del servicio sea afectado), sino que
tambin va en contra de uno de los principios fundamentales de
SOA: los servicios son autnomos. La autonoma es el principio
fundamental de la orientacin al servicio. Los servicios se deben
implementar y modificar/mantener sin tener en cuenta los otros
servicios ni los sistemas que los utilizan.
LA AUTONOMA ES EL PRINCIPIO FUNDAMENTAL DE

LA ORIENTACIN AL SERVICIO. LOS SERVICIOS SE
DEBEN IMPLEMENTAR Y MODIFICAR/MANTENER SIN
TENER EN CUENTA LOS OTROS SERVICIOS NI LOS
SISTEMAS QUE LOS UTILIZAN..
El problema de trabajar con componentes compartidos que
pueden cambiar, no es nuevo. Por ejemplo, el sistema operativo de
Windows y las aplicaciones basadas en Windows dependen de los
componentes COM/ActiveX compartibles. En el caso de COM, se
considera que los componentes son inalterables y cualquier cambio
funcional requiere la introduccin de un nuevo componente con un
Identificador Global nico (GUID). Este enfoque permite la
coexistencia simultnea de varios componentes/versiones.
En este artculo, analizar los enfoques para el control de
versiones de servicios que permiten desarrollar implementaciones de
servicios sin afectar a los consumidores existentes.
Introduccin al versionado de servicios
Uno de los enfoques ms conocidos para tratar los cambios es el
versionado. El versionado implica la existencia simultanea de
Versionado en SOA
Figura 1: Coexistencia de versiones servicios mltiples
Consumidor
del servicio
Consumidor
del servicio
invoca
Consumidor
del servicio
invoca
invoca
Consumidor
del servicio
invoca
Proveedor
del servicio
invoca
Consumidor
del servicio
Cambio
Proveedor
del servicio
invoca
Consumidor
del servicio
mltiples (diferentes) implementaciones de la misma cosa, donde

cada implementacin es distinguible y se puede tratar de un modo
individual. En el caso de SOA, el versionado de servicios iguala a la
coexistencia mltiples versiones del mismo servicio que permite que
cada consumidor utilice la versin que se les dise y prob (Ver
Figura 1). En este caso, se crea una nueva versin de un servicio
basada en los requisitos de uno o ms consumidores, quienes pueden
comenzar a usar esta versin inmediatamente. No es necesario que
EL VERSIONADO DE SERVICIOS BASADO EN EL

MTODO BRINDA UNA FLEXIBILIDAD OPTIMIZADA Y
UNA MEJOR ALINEACIN DE LAS VERSIONES DEL
SERVICIO CON LAS PRCTICAS DE VERSIONADO
HABITUALES DE LOS LENGUAJES DE PROGRAMACIN.
otros consumidores de este servicio comiencen a utilizar la ltima
versin inmediatamente, sino que pueden continuar utilizando las
versiones del servicio que se les dise y prob. Pueden comenzar a
utilizar la ltima versin del servicio basados en su propio programa
de desarrollo y evaluacin. Las mltiples versiones coexistentes del
mismo servicio en el sistema permiten el ciclo de vida independiente
de los servicios y sus consumidores y minimizan el impacto total de la
incorporacin de cambios. Si bien la necesidad de este mecanismo de
versionado puede ser obvia para cualquier persona que siempre ha
trabajado con servicios, este tema an no se ha incorporado en la
corriente principal de implementaciones y publicaciones de SOA. La
idea bsica del versionado de servicios es muy simple y clara, pero su
implementacin requiere la definicin de lo siguiente:
Unidades de versionado
Cambios en el servicio, creacin de una nueva versin
Consideraciones del ciclo de vida de la versin del servicio
Enfoques de acceso/implementacin de la versin
Unidades de versionado
Existen dos opciones principales para definir las unidades de
versionado, cada una con sus propias ventajas y desventajas.
Segn las prcticas actuales de Servicios de Web (la tecnologa de
implementacin de SOA ms conocida en la actualidad), varios
profesionales proponen el versionado de servicios

(incluyendo todas sus operaciones) como un todo. Si bien
este enfoque se alinea bien con las prcticas de desarrollo
basado en componentes (DBC) y orientado al objeto (OO) de
la actualidad, parece que no siempre es apropiado para el
caso de servicios agrupados. (Para una comparacin
adicional de SOA y OO, ver Recursos Defining SOA as an
Architectural Style).
Cuando las personas hablan del versionado en sus
conversaciones diarias, por lo general, hablan de cambios y
versionado de los mtodos, no de un servicio en s mismo.
Por ejemplo, consideremos un servicio de cuentas que
implementa tres operaciones: retiro de dinero, depsitos y
transferencias. Normalmente, la conversacin gira en torno a
los cambios de la operaciones individuales (Ej.: retiro de
dinero) no del servicio de cuentas en s mismo.
Por lo tanto, otra opcin es definir las operaciones del
servicio individual (mtodos) como una unidad de
versionado. Independientemente, las operaciones del servicio
de versionado poseen los siguientes beneficios:
Permite servicios inalterables. El servicio puede brindar mtodos
adicionales (versiones del mtodo), algunos de los cuales pueden ser

desaprobados con el paso del tiempo, pero el servicio en s mismo,
su nombre y clasificacin, nunca cambia. Este esquema se parece a
los enfoques de versionado de los lenguajes de programacin
conocidos, como Java o C#, en los que los mtodos sobre las clases
se agregan y se desaprueban con mucha frecuencia mientras que las
clases existentes que se utilizan mucho, rara vez cambian.
Minimiza el impacto de cambios en el servicio sobre los
consumidores. El cambio slo afecta a los consumidores que utilizan
un mtodo en particular en vez de a todos los consumidores del
servicio.
Reduce la cantidad total de cdigo implementado. Slo los mtodos
que poseen una nueva versin se vuelven a implementar en el
proceso de introduccin de la nueva versin. Los cdigos que
implementan mtodos que no han cambiado, permanecen sin
cambios.
Tambin posee las siguientes desventajas:
Esto requiere que cada mtodo se implemente de modo
independiente con su propia direccin del servicio. (Si bien este

enfoque de implementacin no es convencional en la actualidad,
posee algunas ventajas, como brindar diferentes acuerdos de nivel
de servicio (SLAs) para diferentes mtodos dentro del mismo
servicio).
Requiere un esquema diferente de direccionamiento para invocar el
servicio, un poco ms complejo. En este caso, el consumidor del
servicio, en vez de especificar el servicio que desea invocar, debe
especificar explcitamente el servicio, la operacin y la versin de la
operacin que necesita.
A pesar de los requisitos para el enrutamiento/invocacin del
servicio no estndar, el versionado de servicios basado en el mtodo
brinda una flexibilidad optimizada y una mejor alineacin de las
versiones del servicio con las prcticas de versionado habituales de los
lenguajes de programacin. Tambin minimiza la cantidad de cdigo
que se debe volver a implementar para soportar la nueva versin.
Estas caractersticas hacen que la creacin de versiones basadas en el
mtodo sea un enfoque de versionado de servicios eficaz.
Definiciones de versin
Definir lo que constituye una nueva versin del servicio (mtodo)
requiere el anlisis de los cambios posibles, su impacto potencial sobre
la ejecucin de los consumidores as como tambin la identificacin de
37
Versionado en SOA
aquellos que afectarn. Cualquier cambio en el servicio, ya sea un
cambio en la interfaz o implementacin, que pueda impactar en la
ejecucin del consumidor, debe producir la creacin de la nueva
versin del servicio (mtodo). Si bien la definicin anterior no es muy
precisa y fcil de interpretar, brinda un buen punto de inicio para la
creacin de la nueva versin.
Analizar ms en detalle los componentes principales de la
definicin del servicio (definiciones de mensaje e interfaz) y las
implementaciones para determinar las situaciones particulares que
pueden llevar a la creacin de una nueva versin.
Cambios en la interfaz del servicio
Despus de la adopcin de un modelo semntico de mensajera, las
firmas del mtodo de un servicio nunca cambian (todos los cambios
se reflejan en los cambios del modelo semntico). La interfaz del
mtodo del servicio, en el caso de la mensajera semntica, es la
siguiente:
servicemethod (XML in, XML out)

Por consiguiente, la interfaz del mtodo del servicio nunca cambia
y no se debe considerar en la definicin del versionado. Debido a que
cada mtodo se trata e implementa de forma individual en un esquema

de versionado basado en el mtodo, se pueden incorporar mtodos
adicionales al servicio sin afectar a los consumidores del servicio
existente. Finalmente, puesto que todos los cambios de interfaz estn
contenidos en el modelo de mensajera, la eliminacin del mtodo
(desaprobacin del uso), en este caso, es equivalente a la eliminacin
de alguna funcionalidad de la empresa y debe suceder muy rara vez.
Desde el punto de vista del consumidor, esta situacin requiere
modificaciones (potencialmente significativas), que implican la
implementacin interna de la funcionalidad requerida o el uso de un
servicio completamente diferente. En este caso, el mtodo del servicio
se define como desaprobado y se guarda, mientras que cada uno de
sus consumidores podr dejar de utilizarlo (ver Consideraciones sobre
el ciclo de vida de versiones del servicio ms adelante en este
artculo).
Cambios en el mensaje
Como se defini anteriormente, en el caso de la mensajera semntica,
los cambios en la interfaz del servicio estn contenidos en los cambios
de mensajes semnticos. Estos mensajes se definen utilizando
esquemas que describen su contenido. El uso de esquemas de
mensajera para la definicin de cambios potenciales de la interfaz
Versionado en esquemas XML

El modo ms simple de indicar versiones en esquemas XML es utilizar
un atributo (opcional) en el elemento versin xs:schema. El modelo
del contenido permite la clasificacin Dewey de los nmeros de
versin major.minor (principal.secundaria)
Ya que no se requieren analizadores de XML para validar las
instancias que utilizan la versin, es posible implementar una
representacin personalizada de la versin, permitiendo que el
analizador la incluya en el proceso de validacin. Habitualmente, el
uso de esta tcnica requiere la introduccin de un atributo de
versionado como valor fijo, requerido para identificar una versin del
esquema especfica. Sin embargo, este enfoque para el esquema de
versionado no es muy prctico. Existen varias desventajas:
Una instancia de XML no podr utilizar mltiples versiones de la
representacin de un esquema porque el versionado ocurre en la

raz del esquema.
Las herramientas de validacin del esquema XML no son necesarias
para validar las instancias que utilizan el atributo de la versin; el
atributo se proporciona puramente para documentacin y no es
aplicable por los analizadores de XML.
Debido a que no se necesitan los analizadores de XML para validar
el uso del atributo de la versin, se requiere un procesamiento
personalizado adicional (adems del analizador y la validacin)
para asegurar que la versin del esquema prevista sea
referenciada por la instancia.
La serializacin/deserializacin de datos de documentos de XML
rara vez realiza utilizando manipulacin directa del rbol DOM. El
enfoque habitual para la serializacin de datos es la generacin de
clases que soporten la serializacin de datos automtica con el
uso de herramientas como WSDL2Java, Castor, EMF, SDO, XSD,
XSDObjectGenerator y dems. En este caso, las clases se generan
en paquetes en Java o espacios de nombres en C#, basadas en los
espacios de nombres del esquema, no en la versin del esquema.
Otra opcin para indicar las versiones del esquema es el uso de
espacios de nombre de XML. En este enfoque, un espacio de nombre
nuevo de XML se utiliza para todas las producciones de versiones
38
principales. Este enfoque se ajusta bien con la generacin de cdigo

serializado, permitiendo generar cdigo en diferentes paquetes
(espacios de nombres), posibilitando, de este modo, que un
consumidor del servicio nico trabaje simultneamente con varias
producciones principales del esquema.
Incluso, otra opcin es mantener constantes los valores de los
espacios de nombres de XML y agregar un elemento especial para
agrupar las extensiones personalizadas. Este enfoque contiene
extensiones para el vocabulario subyacente dentro de un elemento de
extensin especial. Est tcnica es favorecida por varios esquemas de
la industria estndar. Por ejemplo, los Open Application Groups
Business Object Documents (OAG BODs) incluyen un elemento
<userarea> que define informacin personalizada que tal vez no es
parte del vocabulario base. Este enfoque optimiza la extensibilidad de
las estructuras del esquema (los esquemas pueden ser compatibles con
versiones anteriores o futuras) sin la introduccin de espacios de
nombres nuevos. Existen dos desventajas para este enfoque:
Introduce significativamente niveles ms altos de complejidad dentro

del esquema.
No permite la implementacin de extensiones mltiples entre las

diferentes porciones de la instancia de XML ya que todas las
extensiones deben agruparse dentro del contenedor de
extensiones.
El enfoque ms escalable para el versionado de esquemas es el

siguiente:
Componentizacin del esquema total en particiones lgicas utilizando

espacios de nombres mltiples, por lo tanto, contiene cambios.
Definicin de un espacio de nombres nuevo (que refleje informacin
de la versin principal) para todas las versiones principales de cada

esquema.
Indicacin de todas las versiones secundarias como una versin del
esquema en un espacio de nombres de la versin principal. Debido a
que las versiones secundarias son compatibles con versiones
anteriores, el cdigo serializado generado, tambin lo ser.
Versionado en SOA
alinea este enfoque con las tcnicas de versionado del esquema de
XML (Ver la seccin Versionado en esquemas XML), y por lo tanto,
permite la representacin directa del versionado en los mensajes del
servicio. En trminos generales, los cambios en el esquema se
pueden definir en tres categoras principales:
Las Revisiones representan los cambios en el esquema del
documento. Por ejemplo, un cambio en un espacio en blanco,
formateo, documentacin no normativa, comentarios y dems. La
revisin de una versin que ya ha sido publicada no debe afectar la
funcionalidad de los consumidores ni de las implementaciones del
servicio.
Adems, el desarrollo gradual inicial de un esquema semntico,
antes de que se publique para uso productivo, tambin se puede
tratar como una revisin de la misma versin.
Los cambios secundarios representan los cambios compatibles
con versiones anteriores en el esquema del documento. Los ejemplos
de cambios secundarios en el esquema incluyen:
Cambiar la posibilidad de opcin de un elemento local o una

referencia de un elemento de requerido a opcional
Agregar un tipo o elemento global

Agregar elementos opcionales a tipos existentes
Cambiar el tipo de un elemento global o local a un tipo nuevo,
derivado del original, agregando/restringiendo elementos
opcionales.
Los cambios importantes representan cambios no compatibles

con versiones anteriores en el esquema del documento.
Ejemplos de cambios principales en el esquema incluyen:
Cambiar el tipo de un elemento local o global a un tipo nuevo,

derivado del original, agregando/restringiendo elementos
opcionales
Cambiar la posibilidad de opcin de un elemento local o una
referencia de un elemento de opcional a requerido
Agregar o eliminar un valor de enumeracin
Eliminar o dar un nuevo nombre a un elemento o tipo global.
Segn las definiciones anteriores, tanto las revisiones como los

cambios secundarios en el esquema de mensajera ofrecen
compatibilidad con versiones anteriores y no afecta el contrato del
servicio. Como consecuencia, no impacta la implementacin del
consumidor ni del servicio y no requieren el versionado de servicios.
En cambio, los cambio importantes requieren el versionado del
esquema de mensajera y por consiguiente, de los servicios.
Figura 2: Implementacin del versionado con el uso del pacto
Implementacin
Versin 1
Consumidor
del servicio
Invocar
Servicio/
Mtodo/
Versin con
carga til
adecuada
Direccin
terminal
mtodo
servicio
...
Implementacin
Versin 2
Implementacin
Versin n
Cambios en la implementacin
Una creencia errnea comn es que, debido a que los servicios se
definen a travs de la interfaz, no de la implementacin, los cambios
en la implementacin del servicio no afectarn a los consumidores del
servicio y no requieren la creacin de versiones.
En realidad, la adherencia a la interfaz no constituye la capacidad de
cambio de las implementaciones. La capacidad de cambio no est
definida por la interfaz sola, sino ms bien por el contrato, que incluye
la interfaz, pre y post condiciones y ciertos SLAs sobre los cuales se
basa el consumidor del servicio. Por consiguiente, el versionado se
requiere cuando los cambios en la implementacin del servicio afectan
el contrato sobre el cual se basa un consumidor del servicio particular.
Debido a que los diferentes consumidores del servicio pueden basarse
en diferentes partes del contrato de servicio, cada cambio en la
implementacin del servicio debe ser validada para todos los
consumidores del servicio existente para garantizar que no se
incumplan los contratos.
UNA CONSIDERACIN IMPORTANTE DEL VERSIONADO

ES DEFINIR LA CANTIDAD DE TIEMPO QUE SE
CONSERVAR UNA VERSIN DEL SERVICIO (MTODO).
EL CICLO DE VIDA ADECUADO PARA LAS VERSIONES
DEL SERVICIO (MTODO) VARA SIGNIFICATIVAMENTE
Y EST DEFINIDA POR LA CAPACIDAD DE LA
ORGANIZACIN DE HACER FRENTE A LOS CAMBIOS.
A continuacin se detallan algunos ejemplos de cambios en la
implementacin (mtodo) del servicio puede llevar a cambios en el
contrato:
La nueva implementacin del servicio soporta exactamente la misma
interfaz (funcionalidad), pero cambia el tiempo de ejecucin (SLA).

Si un consumidor del servicio invoca este servicio (mtodo)
sincronizadamente, ese cambio puede afectar significativamente la
ejecucin del consumidor del servicio. Como resultado, es posible
que se necesite la creacin de versiones. (Curiosamente, volver a
implementar un servicio existente, con cambios en su
implementacin, puede producir los mismos resultados).
La nueva implementacin del servicio soporta la misma interfaz,
pero cambia las validaciones de los parmetros entrantes
(precondiciones). En este caso, algunas solicitudes que se han
procesado de un modo exitoso, ahora sern rechazadas, requiriendo
la introduccin de un nuevo servicio.
La nueva implementacin del servicio introduce una nueva
implementacin de seguridad (precondicin), que por lo general no
se refleja en la interfaz del servicio, sino ms bien a travs de las
opciones de configuracin. (Ver Recursos Web Services Handbook for
WebSphere Application Server Version 6.1 by Wahli et al. and Web
Service Security by Hogg et al).
En este caso, los consumidores del servicio existente necesitarn
enviar credenciales de seguridad se requiere un cambio en la
implementacin y la creacin de una nueva versin.
Cada uno de estos escenarios requiere el anlisis de los
consumidores del servicio existente y potencialmente, pruebas
exhaustivas. Como resultado, un modo ms simple de decidir si es
necesario crear una nueva versin del servicio (mtodo) cuando
cambia la implementacin del servicio, es mantener una definicin del
contrato del servicio (mtodo) y crear una nueva versin cuando
cambia el contrato, sin tener en cuenta qu consumidor depende de
qu parte del contrato. Ante la duda, por lo general es ms simple
crear una nueva versin.
39
Versionado en SOA
problema puede ser an ms complejo que el versionado de servicios.
Se puede lograr una mejora an mayor si se reemplaza con un
agente externo (mediador) el enrutador local que realiza el envo
entre la implementacin de las versiones del servicio. En este caso,
todas las versiones se pueden implementar de un modo independiente
y es responsabilidad del mediador establecer un vnculo de forma
Consumidor 1
Servicio 1
dinmica con la direccin terminal de la versin del servicio deseado y
(utiliza
Invoca
Mtodo 1
enviar todos los mensajes de acuerdo con esto. Sin embargo, a pesar
Servicio 1
Versin 1
de que los intermediarios (mediaciones) son promocionados en las
Mtodo 1
publicaciones ESB como la solucin para la mayora de los problemas
Versin 1)
de transformacin/enrutamiento que se encuentran en la Arquitectura
Orientada al Servicio, existen inconvenientes asociados con ellos.
Servicio 1
Normalmente, disminuyen el rendimiento. Tambin debe soportar el
Mtodo 1
SLA ms estricto de todos los servicios que se acceden a travs de
Versin 2
ste, que podra ser un requisito muy fuerte.
Direcciones terminales mltiples. En este caso, al igual que con
Consumidor 2
la implementacin del mediador, cada versin de una operacin
(utiliza
determinada se implementa en su propia direccin terminal. La
Invoca
Servicio 2
diferencia aqu es que cada direccin terminal se expone directamente
Servicio 1
Mtodo 2
para un consumidor del servicio (Ver Figura 3).
Mtodo 1
Versin 2)
Las direcciones terminales mltiples implican que un consumidor del
Versin n
servicio puede establecer un vnculo con una direccin terminal (por lo
general, utilizando un registro del servicio) para una versin necesaria
Consideraciones sobre el ciclo de vida de versiones del servicio basada en la informacin de la versin/mtodo/servicio. La ventaja de
Una de las consideraciones ms importantes del versionado es definir este esquema es una separacin completa de la implementacin de
versiones mltiples del mtodo. La desventaja es un paradigma de
la cantidad de tiempo que se conservar una versin del servicio
direccionamiento ms complejo que requiere soporte de registro del
(mtodo). Extender este perodo produce la necesidad de conservar
servicio para establecer un vnculo con la direccin terminal.
cantidades excesivas de versiones del servicio. Por otro lado, reducir
El enfoque de direccin terminal mltiple, habitualmente, brinda una
el perodo, limita el tiempo para que los consumidores del servicio
implementen las actualizaciones necesarias. El ciclo de vida adecuado mejor escalabilidad (un salto menos de red) y disminuye el
acoplamiento entre las versiones mltiples de la misma operacin.
para las versiones del servicio (mtodo) vara significativamente y
est definida por la capacidad de la organizacin de hacer frente a los
Versionado de la Infraestructura del servicio
cambios.
Una variante para la creacin de versiones de servicios es el versionado
de la infraestructura del servicio, que puede requerir lo siguiente:
Enfoques de acceso/implementacin de la versin
Figura 3: Implementacin de versiones utilizando direcciones
terminales expuestas directamente
...
Existen dos enfoque comunes para la implementacin de las

Cambios en el transporte, por ejemplo, cambiar el transporte de
versiones del servicio:
HTTP a Java Message Service (JMS).
Pacto o Parmetro de la versin. Un pacto es un acuerdo if Cambios en el cdigo del mensaje, por ejemplo, actualizando el
then-else (si t haces esto, entonces yo hago esto). En este caso,
empaquetado propietario con el Protocolo de Acceso a Objetos
hay una direccin terminal nica para todas las versiones del servicio
Simple (SOAP).
(mtodo), como se muestra en la Figura 2.
El pacto realmente implementa el enrutamiento basado en el
Cambios en el esquema de direccionamiento, por ejemplo,
contexto, toma un mensaje entrante y lo enruta (basado en un
introduccin del Direccionamiento de Servicios de Web para
parmetro de la versin, incorporado en el mensaje de invocacin)
especificar la direccin de respuesta.
hacia la versin adecuada del servicio. El beneficio de este enfoque
es que simplifica el
direccionamiento del servicio, Figura 4: Interoperabilidad entre infraestructuras del servicio
desde el punto de vista del
consumidor. El consumidor,
en este caso, utiliza una
direccin terminal nica para
Fachada del
Fachada del
Consumidor
Proveedor
acceder a todas las versiones
proveedor
proveedor
del servicio
del servicio
de un determinado servicio
del servicio
del servicio
Infraestructura
Infraestructura
(mtodo) y codifica el
del Servicio 1
del Servicio 2
mtodo necesario en el
Adaptador
mensaje de invocacin. Una
direccin terminal
implementa un soporte de enrutamiento, invocando una versin
En este caso, siempre se prefiere implementar la compatibilidad con
requerida.
versiones anteriores asegurando que la nueva infraestructura pueda
Si bien el enfoque del pacto minimiza el impacto de incorporar
comprender y soportar los mensajes que produce la infraestructura
nuevas versiones sobre el consumidor del servicio, tambin presenta
anterior y pueda producir mensajes compatibles con sta. En realidad,
la complejidad de combinar mltiples versiones de un mtodo de
esto puede ser muy costoso o an imposible desde el punto de vista
servicios. Esto puede provocar colisiones de nombres de clase,
tcnico.
colisiones de nombres de bases de datos, etc. Asimismo, este
Trasladar todos los consumidores e implementaciones del servicio
enfoque realmente requiere una estrategia de versionado, no slo
existente a la nueva infraestructura es por lo general bastante costoso
para los servicios en s mismos, sino tambin para los componentes
y se le debe dedicar demasiado tiempo, requiriendo soporte del
que se utilizan en las implementaciones de los servicios. Si se tiene
versionado que proporciona interoperabilidad entre dos infraestructuras
en cuenta el alto grado de acoplamiento entre los componentes, este
de servicio diferentes. La solucin ms usada para este problema es un
40
Versionado en SOA
adaptador del servicios (Ver Figura 4).
En este caso, cuando el consumidor del servicio, que tiene soporte
de la infraestructura del servicio 1, invoca al proveedor del servicio,
con soporte de la infraestructura del servicio 2, la llamada pasa por el
adaptador realizando una mediacin entre las infraestructuras del
servicio. Desde el punto de vista del consumidor del servicio, el
adaptador funciona como un proveedor de servicios. El adaptador
entonces invoca al proveedor del servicio, actuando como un
consumidor del servicio.
La implementacin se puede combinar con la topologa de
implementacin de versionado de servicios (Figura 4) para brindar
soporte en el versionado tanto a los servicios as como tambin a los
consumidores del servicio entre infraestructuras diferentes.
Conclusin
Enfrentar los cambios, nunca es sencillo y, por lo general, la
complejidad aumenta con la dimensin de la implementacin.
Habitualmente, las implementaciones ms grandes tienen ms partes
movibles interdependientes, y por consiguiente, los efectos del
cambio son ms generales. Las implementaciones de SOA, en
especial las implementaciones que afectan a toda la empresa, no son
la excepcin.
Los enfoques de versionado de servicios que se describen en este
artculo, llevan a la creacin de implementaciones de SOA de
estructura mucho ms flexible. La introduccin de versiones mltiples
del servicio implementadas de forma simultnea permiten que tanto
los consumidores del servicio como los proveedores evolucionen de
modo independiente, con sus propios programas de implementacin y
desarrollo. El versionado independiente de los mtodos del servicio
minimiza el impacto de la creacin de versiones y reduce la cantidad
de cdigo implementado. Finalmente, el uso de mensajera semntica
para las definiciones de interfaz del servicio hace que las
implementaciones del servicio sean ms flexibles al cambio.
Agradecimientos
El autor agradece a Jim McKune, Dmitry Tyomkin, Kiran Achen y Luc
Clement por sus contribuciones.
Josh Lee, Microsoft 2005

http://msdn.microsoft.com/architecture/thinkahead/default.aspx?
pull=/library/en-us/dnbda/html/aisforsoa.asp
Principles of Service Design: Service Versioning, John Evdemon,
Microsoft 2005
dnbda/html/SOADesignVer.asp
Web Services Handbook for WebSphere Application Server Version 6.1
(Draft IBM Redbook), Ueli Wahli, Owen Burroughs, Owen Cline, Alec
Go, Larry Tung
http://www.redbooks.ibm.com/redpieces/abstracts/sg247257.
html?Open
Web Service Security. Scenarios, Patterns, and Implementation
Guidance for Web Services Enhancements (WSE) 3.0, Jason Hogg, Don
Smith, Fred Chong, Dwayne Taylor, LonnieWall, y Paul Slater
(Microsoft Press, 2005)
dnpag2/html/wssp.asp
Patterns: Implementing an SOA using an Enterprise Service Bus in
WebSphere Application Server V6, Martin Keen, Oscar Adinolfi, Sarah
Hemmings, Andrew Humphreys, Kanthi Hanumanth, Alasdair
Nottingham, IBM Redbooks, 2005
http://www.redbooks.ibm.com/abstracts/sg246494.html?Open
Supporting Policies in Service-Oriented Architecture, Boris Lublinsky,
IBM developerWorks, 2004
http://www-128.ibm.com/developerworks/webservices/library/
ws-support-soa/
Toward a Pattern Language for Service-Oriented Architecture and
Integration, Part 1: Build a service eco-system, Ali Arsanjani, IBM
developerWorks, Julio 2005
http://www-128.ibm.com/developerworks/webservices/library/wssoa-soi/
Recursos
Defining SOA as an Architectural Style, Boris Lublinsky, IBM
developerWorks, Enero 2007
http://www-128.ibm.com/developerworks/architecture/library/
ar-soastyle/
Principles of Service Design: Service Patterns and Anti-Patterns,
John Evdemon, MSDN, Agosto 2005
dnbda/html/SOADesign.asp
Best Practices for Web Services Versioning, Kyle Brown, Michael
Ellis, IBM developerWorks, 2004
http://www-128.ibm.com/developerworks/webservices/library/
ws-version/
A SOA Version Covenant, Rocky Lhotka
http://www.theserverside.net/articles/showarticle.tss?id=
SOAVersioningCovenant
XFire User Guide, Versioning Best Practices
http://docs.codehaus.org/display/XFIRE/Versioning
Architecting Industry Standards for Service Orientation,
Sobre el autor
Boris Lublinsky posee ms de 25 aos de experiencia en arquitectura
tcnica e ingeniera del software. Desde hace varios aos se dedica a la
Arquitectura Empresarial, SOA y Administracin de Procesos. A lo largo
de toda su carrera, el Dr. Lublinsky ha sido autor y orador tcnico
asiduo. Posee ms de 40 publicaciones tcnicas en diferentes revistas
que incluyen: Avtomatika i telemechanica, IEEE Transactions on
Automatic Control, Distributed Computing, Nuclear Instruments and
Methods, Java Developers Journal, XML Journal, Web Services Journal,
JavaPro Journal, Enterprise Architect Journal y EAI Journal.
Actualmente, el Dr. Lublinsky trabaja para una gran Compaa de
Seguros en la que sus responsabilidades incluyen el desarrollo y
mantenimiento de estructuras y estrategias de SOA. Puede contactarlo
en blublinsky@hotmail.com.
41
098-107719

Arquitectura de Infraestructura

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitectura de Infraestructura

Cargado por

Copyright:

Formatos disponibles

Aprenda la disciplina,

Por Simon Guest

Arquitecturas de alta disponibilidad para hosting masivo

Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael Johnson

Brindar informtica integral de alta productividad

Por Marc Colmes y Simon Cox

Infraestructuras orientadas a pruebas

Por Mario Cardinal

Perfil del Architecture Journal: Don Ferguson

Resolver el dilema de la integracin

Por Jim Wilt

Ontologa y Taxonoma de los Servicios en una Arquitectura

Por Shy Cohen

Por Boris Lublinsky

La idea de versionado de servicios es simple, pero la implementacin requiere mucha reflexin y

que sirven de base. www.architecturejournal.net

La informacin contenida en The Arquitecture

2005 Microsoft Corporation. Todos los derechos

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Por Shaun Hirschman, Mathew Baldwin, Tito Leverette y Michael

Historia de la industria del hosting y problemas actuales

Estos mdulos son fciles de imaginar y de rpida implementacin,

EL OBJETIVO PRIMARIO AL DISEAR UNA

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Arquitecturas de alta disponibilidad para hosting masivo

Figura 1: Modelo de distribucin de carga de la aplicacin

Modelos de distribucin de carga

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Arquitecturas de alta disponibilidad para hosting masivo

100% 90% 80% 70% -

50% 40% 30% 20% 10% 0%Aislamiento

Distribucin de carga conjunta

de aplicaciones asignado a una aplicacin nica o en un escenario de

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Arquitecturas de alta disponibilidad para hosting masivo

placa. Las secciones que se detallan a continuacin dividen las

LA INCORPORACIN DE LA ARQUITECTURA DE 64BITS LE HA PERMITIDO A VARIOS HOSTERS DARSE EL

Planificacin de un grupo de aplicaciones con alta

Almacenamiento conectado a la red (NAS)

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Arquitecturas de alta disponibilidad para hosting masivo

NO EXISTE UN MODO RENTABLE DE CONSTRUIR UNA

Deben brindar un alto grado de servicio para mantener la lealtad del

Sobre los autores

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Diseada para una solucin a un problema especfico

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net

Informtica de alta productividad

Figura 1: Los esfuerzos para mejorar la velocidad del procesamiento

Para mejorar la velocidad de los procesamientos, un equipo de

Utilizar ms o mejor hardware. Los beneficios de los procesadores

Existe, por supuesto, un modo simple de mejorar el valor de una

Sin embargo, la realidad es que es muy probable que los clculos

ms rpidos, discos ms rpidos, mayor memoria, etc., podran estar

Figura 2: Escenario de informtica general

www.architecturejournal.net - Journal 11 THE ARCHITECTURE JOURNAL

Informtica de alta productividad

arquitectura posible y algunas caractersticas de esta arquitectura as

Ciencia ambiental de alta productividad integral

para comprender el sistema terrestre. Los simulacros del sistema

En Supercomputing 2006, en Tampa, Fla., mostramos el modo en el

Microsoft Institute of High Performance

Interfaz de Web del cliente

THE ARCHITECTURE JOURNAL Journal 11 www.architecturejournal.net