1 criterios para escoger y evaluar las arquitecturas

TABLA DE CONTENIDO
1
CRITERIOS PARA ESCOGER Y EVALUAR LAS ARQUITECTURAS .......................... 5
2
OPCIONES DE ARQUITECTURAS PARA IMPLEMENTAR P2P EN DISPOSITIVOS
MÓVILES .................................................................................................... 6
2.1. ARQUITECTURA BASADA EN RELAYS ........................................................... 7
2.2. P2P PURA................................................................................................. 9
3
INTEGRACIÓN DE LAS ARQUITECTURAS P2P ................................................ 11
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
P2P PUNTOS COMUNICADOS POR RELAY .................................................... 12
P2P CON SERVIDOR DE ÍNDICES CON PUNTOS COMUNICADOS POR RELAY .... 15
SERVIDOR DE ÍNDICES Y BÚSQUEDAS ...................................................... 16
P2P SERVIDOR ÍNDICES .......................................................................... 18
P2P CON SERVIDOR DE INDICES Y BUSQUEDAS .......................................... 19
P2P CON SERVIDOR DE INDICES Y SIN BUSQUEDAS .................................... 21
4
MÉTODO PARA ESCOGER LA ARQUITECTURA DEL API DE COMUNICACIONES ... 22
5
DISEÑO DE LA ARQUITECTURA ................................................................... 24
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
DISEÑO DE PAQUETES ............................................................................ 24
PAQUETE CLIENTE: ..................................................................................... 25
PAQUETE ÍNDICES....................................................................................... 26
PAQUETE COMUNICACIONES ........................................................................... 26
PAQUETE DE TIPOS ..................................................................................... 27
PAQUETE DE SERVICIOS................................................................................ 27
6
SERVICIOS A IMPLEMENTAR ....................................................................... 29
7
OTROS SERVICIOS .................................................................................... 30
8
REFERENCIAS ........................................................................................... 31
ÍNDICE DE TABLAS
Tabla 1. Selección de Arquitectura a Implementar. ............................................. 23
Tabla 2. Rangos de Calificación ........................................................................ 23
ÍNDICE DE GRAFICAS
Gráfica 1. Diagrama de Arquitectura Basada en Relays ......................................... 7
Gráfica 2. Diagrama de Secuencias de la Arquitectura Basada en Relays ................. 8
1
CRITERIOS
PARA
ESCOGER
Y
EVALUAR
LAS
ARQUITECTURAS
Como objetivo especifico de la primera etapa del Proyecto de
Investigación, se pretende establecer el diseño de la arquitectura
y del API de comunicaciones, para escoger y evaluar nuestra
decisión se tuvieron en cuenta los siguientes criterios:
•
Posible
disponibilidad
implementación
de
los
de
un
aspectos,
código
pues
abierto
nos
para
la
ayudaría
a
independizar esta parte con el API en concreto.
•
Flexibilidad en la forma de la creación de servicios y fácil
extensibilidad del API para futuras implementaciones.
•
Baja
complejidad
en
la
construcción
y
futuro
mantenimiento del API.
•
Agilidad en la adquisición de conocimientos en la curva de
aprendizaje.
•
Uso de recursos físicos (memoria, procesador) donde se
implementarán los servicios del API.
•
El uso de la comunicación y del canal de red, distribución
de la carga, flujo de paquetes.
•
Parte técnica: que existe en POA que sea soportado por
Compact Framework para brindar servicios de comunicación
2
OPCIONES DE ARQUITECTURAS PARA IMPLEMENTAR P2P EN
DISPOSITIVOS MÓVILES
Existen básicamente una forma conocida para implementar
soluciones P2P en dispositivos móviles y es la planteada por
JXTA para J2ME, basada en Relays. Sin embargo Microsoft .Net
Framework es una herramienta poderosa para implementar
soluciones de
comunicación por
su simplicidad.
Según el
documento de MSDN Magazine. ”NET P2P: Writing Peer-to-Peer
Networked Apps with the Microsoft .NET Framework” [OLSN] las
maneras de implementar P2P son:

P2P puro

P2P con servidor de descubrimiento simple

P2P con servidor de descubrimiento y búsquedas

P2P
con
servidor
de
descubrimiento,
búsquedas
y
contenido
JXTA para J2ME es una implementación P2P pura, sin embargo la
comunicación entre la red y los dispositivos móviles se hace a
través de Relays. Pero no es la única manera de montar P2P en
dispositivos móviles.
2.1. ARQUITECTURA BASADA EN RELAYS
Puntos Wireless
Red P2P
Relay
Aplicaciones
Cliente
Puntos Wireless
Relay
Aplicación Servidor con
Servicios Basados en Aspectos
Aplicaciones
Cliente
Gráfica 1. Diagrama de Arquitectura Basada en Relays
Un patrón Proxy provee un sustituto u objeto que asume el lugar
de otro, que controla el acceso al objeto el cual se esta
reemplazando [GAMM].
Esta es la filosofía de los Relay, en
donde reside los servicios que resultarían pesados (en términos
de recursos de máquina) en los dispositivos móviles.
Gráfica 2. Diagrama de Secuencias de la Arquitectura Basada en
Relays
El anterior diagrama de secuencia muestra la comunicación entre
dos puntos de la red P2P. El primer punto busca el servicio en la
red preguntando a los demás puntos, una vez se ha encontrado
el servicio el punto que los posee se le retorna.
2.2. P2P PURA
Red P2P
Una arquitectura P2P pura es aquella que descubre manera
dinámica los demás puntos, de esta manera obtiene los servicios
que se desea, para ello es usual utilizar una comunicación
broadcast.
En el diagrama de secuencias anterior se muestra como un
punto se desea conectar a la red P2P, para esto el punto tiene la
responsabilidad de recorrer la red buscando a cada uno de los
puntos notificándoles su llegada. Los demás deben actualizar su
caché con el nuevo punto, igualmente el punto que se acaba de
conectar actualiza su caché.
Luego cuando el punto desea buscar un servicio, éste debe
recorrer el caché para obtener la dirección de los demás puntos
e ir a preguntarle a cada punto si posee el servicio. Una vez
encontrado servicio se posee hacer la transmisión de datos entre
los dos puntos.
Esta solución elimina los Relay lo que implica que los servicios
van a residir en los dispositivos móviles, como los servicios que
se pretenden prestar van a estar encapsulados en aspectos la
implementación de estos utilizando MS Compact Framework .Net
es muy limitada, ya que tan solo el Add-in de Mesalem [ADDM],
(que es una implementación de código cerrado) brinda el soporte
para POA.
3
INTEGRACIÓN DE LAS ARQUITECTURAS P2P
A continuación se analizarán las ventajas y desventajas de cada
una de las posibles arquitecturas que podría adoptar el API de
comunicaciones, basados en los criterios expuestos en el punto 1
de este documento y en los modelos P2P para dispositivos
móviles del punto 2.
Las siguientes arquitecturas han sido las escogidas, ya que
soluciones con servidores de contenido son bastante ineficientes
porque el servidor es el encargado de obtener cada uno de los
servicios que se van a publicar; esto implica que cada vez que se
conecta un punto al servidor el punto debe descargar todos los
servicios que va publicar en el servidor, si estos servicios fueran
archivos, en algún momento el servidor se desbordaría, lo que
implica que esta solución está limitada por la capacidad del
servidor.
Las implementaciones con servidores de descubrimiento pero sin
búsquedas no explotan la escalabilidad de las implementaciones
con servidores tanto de búsquedas como de descubrimiento.
Adicionalmente una implementación con tan sólo servidores
descubrimiento hace el tráfico de la red sea más alto, por tal
motivo y aunque si se tuvo en cuenta estas implementaciones,
se
ha
decidido
no
optar
en
implementar
el
API
comunicaciones con tan sólo servidores de descubrimiento.
de
3.1. P2P PUNTOS COMUNICADOS POR RELAY
Red P2P
Relay
Relay
Esta arquitectura implementa una solución P2P pura, pero la
comunicación entre los dispositivos móviles y la red P2P se hace
a través de Relays, estos liberarán de servicios pesados (en
términos de recursos de máquina) a los dispositivos móviles.
Cuando un dispositivo móvil se desea conectar a la red P2P
deben notificar a su Relay, éste se encarga de notificar a los
demás puntos utilizando los protocolos P2P establecidos y
brindándole al mensaje servicios de conexión, transmisión,
búsquedas y seguridad entre otros.
Una vez se ha notificado a todos los puntos de la red que se ha
conectado el dispositivo móvil, estos actualizan su caché y
finalmente el dispositivo móvil también debe actualizar su caché.
Cuando el dispositivo móvil quiere hacer una búsqueda en la red,
éste debe recorrer cada una de las direcciones almacenadas en
el caché y con la ayuda del Relay preguntar a los demás puntos
si posee el servicio, una vez encuentre el punto con el servicio se
procede a hacer la transmisión de datos.
Esta arquitectura nos brinda la posibilidad de implementar
servicios basados en POA y contar con implementaciones
robustas y que proveen código abierto, por consiguiente la
implementación de servicios es bastante flexible y conveniente.
El hecho utilizar Relays hace que la implementación del API
tenga que preocuparse por el canal de comunicación entre el
Relay y los dispositivos móviles; además el P2P no es muy
escalable y el trafico de red es alto; adicionalmente implementar
una
solución
dinámica
implica
utilizar
(en
principio)
comunicación broadcast lo cual puede ser costoso en términos
de
desarrollo,
seguridad
y
demás
[OLSN].
La
tecnología
disponible a implementar POA para esta solución específica es
sencilla, lo que es una ventaja en la curva aprendizaje. Al utilizar
un Relay los servicios residen en este, optimizando el uso de
recursos de máquina del dispositivo móvil, razón por la cual el
proyecto JXME emplea Relays.
El soporte de MS Compact Framework .NET para crear una
aplicación cliente que se comunique con el Relay no es un
problema, principalmente porque los aspectos no van a residir
en los dispositivos móviles sino en el Relay.
3.2. P2P
CON
SERVIDOR
DE
ÍNDICES
CON
PUNTOS
COMUNICADOS POR RELAY
Red P2P
Servidor de
Indices
Relay
Relay
Esta arquitectura implementa una solución utilizando un servidor
en el cual se publican las direcciones de todos los puntos de la
red, adicionalmente cuando un punto hace una búsqueda le pide
a este servidor que le vuelva la lista de los puntos que poseen el
servicio. Este modelo es bastante eficiente ya que optimiza el
tráfico de red, adicionalmente es un modelo escalable a bajo
costo en tiempo de desarrollo [OLSN].
La comunicación entre los dispositivos móviles y la red P2P se
hace a través de Relays, estos liberarán de servicios pesados (en
términos de recursos de máquina) a los dispositivos móviles.
Se va a analizar la arquitectura del Servidor de Índices y
Búsquedas con Relay, ya que implementar la solución sin
búsquedas fue descartada en el punto 3 de este documento.
3.3. SERVIDOR DE ÍNDICES Y BÚSQUEDAS
Cuando un dispositivo móvil desea buscar los servicios le pide al
Relay que busqué en el servidor de índices la dirección de los
puntos que poseen el servicio. El servidor de índices posee una
lista con la dirección y los servicios que tiene publicado cada
punto, una vez encuentre los servicios, el servidor retorna una o
todas las direcciones de los puntos al Relay. El Relay le comunica
al dispositivo móvil la dirección del servicio y éste empieza a
establecer la comunicación directa a través de los protocolos P2P
que provee el Relay.
Esta arquitectura nos brinda la posibilidad de implementar
servicios basados en POA y contar con implementaciones
robustas y que proveen código abierto, por consiguiente la
implementación de servicios es bastante flexible y conveniente.
El hecho utilizar Relays hace que la implementación del API
tenga que preocuparse por el canal de comunicación entre el
Relay y los dispositivos móviles. La tecnología disponible a
implementar POA para esta solución específica es sencilla, lo que
es una ventaja en la curva aprendizaje. Al utilizar un Relay los
servicios residen en este, optimizando el uso de recursos de
máquina del dispositivo móvil, razón por la cual el proyecto JXME
emplea Relays.
El soporte de MS Compact Framework .NET para crear una
aplicación cliente que se comunique con el Relay no es un
problema, principalmente porque los aspectos no van a residir
en los dispositivos móviles sino en el Relay.
3.4. P2P SERVIDOR ÍNDICES
Red P2P
Servidor de
Indices
Esta arquitectura implementa una solución utilizando un servidor
en el cual se publican las direcciones de todos los puntos de la
red, adicionalmente cuando un punto hace una búsqueda le pide
a este servidor que le vuelva la lista de los puntos que poseen el
servicio. Este modelo es bastante eficiente ya que optimiza el
tráfico de red, adicionalmente es un modelo escalable a bajo
costo en tiempo de desarrollo [OLSN].
Esta solución elimina los Relay lo que implica que los servicios
van a residir en los dispositivos móviles, como los servicios que
se pretenden prestar van a estar encapsulados en aspectos la
implementación de estos utilizando MS Compact Framework .Net
es muy limitada, ya que tan solo el Add-in de Mesalem [ADDM],
(que es una implementación de código cerrado) brinda el soporte
para POA.
3.5. P2P CON SERVIDOR DE INDICES Y BUSQUEDAS
Cuando un dispositivo móvil desea buscar los servicios le pide al
servidor de índices la dirección de los puntos que poseen el
servicio. El servidor de índices posee una lista con la dirección y
los servicios que tiene publicado cada punto, una vez encuentre
los servicios, el servidor retorna una o todas las direcciones de
los puntos al dispositivo móvil, luego éste empieza a establecer
la comunicación directa con el punto seleccionado.
Como se explicó antes, el hecho de que los servicios residen en
el dispositivo móvil hace que la implementación del API esté
fuertemente
acoplada
al
proveedor
para
soluciones
POA
denominado Add-in de Mesalem [ADDM], el cual es código
cerrado. La flexibilidad en la creación de nuevos servicios no es
tan trivial. Existen varias limitantes a nivel de lenguaje de
programación, aunque implementar aspectos con Mesalem es
bastante
sencillo
no
siempre
funciona
en
MS
Compact
Framework, teniendo que recurrir a un código complejo para
lograr el éxito de una aplicación POA ya que MS Compact
Framework no provee la totalidad de funcionalidad que trae el
Framework de .NET.
Como no se cuentan con Relays, todos los servicios, tanto los
básicos que toda red P2P debe poseer y que se muestran en el
punto 6 de este documento, como los servicios encapsulados en
aspectos que se muestran el punto 7 de este documento van a
residir en el dispositivo móvil, lo que implica un consumo de
recursos mayor haciendo esta solución o sea tan óptima.
3.6. P2P CON SERVIDOR DE INDICES Y SIN BUSQUEDAS
Esta solución no explotan en su totalidad el servidor de índices,
por
tal
motivo
fue
descartada
como
implementar el API de comunicaciones.
arquitectura
para
4
MÉTODO PARA ESCOGER LA ARQUITECTURA DEL API DE
COMUNICACIONES
Para escoger entre las arquitecturas mencionadas anteriormente
se utilizará el método descrito en [KINN]. En el cual basados en
los criterios planteados en el punto 1, se hará una cuantificación
de las arquitecturas para escoger la que mejor se acomode al
proyecto de investigación.
Cada criterio posee un peso, que indica la importancia dentro del
desarrollo del API de comunicaciones. A multiplicar éste peso por
la calificación que obtuvo cada arquitectura en determinado
criterio y sumándolas se obtiene la calificación total de la
arquitectura.
Los peso de los criterios fueron establecidos de acuerdo a la
experiencia en desarrollar aplicaciones distribuidas y van en una
escala de 1 a 10.
La calificación de la arquitectura en cada criterio está valuada
por:

Malo: con calificación de 1

Regular: con calificación de 3

Bueno: con calificación de 5
Código
Abierto
Flexibilid
ad
Agilidad en
Baja complejidad
Creación
la curva
Implementación
nuevos
aprendizaje
servicios
Recursos
máquina
PPC
Comunicación
distribución de
carga y envío
de paquetes
Soporte
CF
Total
Pesos De los Criterios
2
3
2
2
5
5
4
P2P con Puntos
comunicados por
Relay
5
5
3
5
5
1
5
91
P2P con servidor de
indices(sin búsquedas)
y puntos comunicado
por Relays
5
3
3
5
3
1
5
75
5
5
5
5
5
3
5
105
1
3
3
3
1
3
3
55
1
3
3
3
1
5
3
65
P2P con servidor de
indices(con
búsquedas) y puntos
comunicado por
Relays
P2P pura con servidor
de indices (sin
búsquedas)
P2P pura con servidor
de indices (con
búsquedas)
Tabla 1. Selección de Arquitectura a Implementar.
Bueno
Regular
Malo
5
3
1
Tabla 2. Rangos de Calificación
Como se puede observar, la arquitectura que obtuvo un mejor
resultado en la comparación fue “P2P con servidor de índices
(con búsquedas) y puntos comunicado por Relays”, por tal
motivo, será la arquitectura escogida para el desarrollo de esta
investigación y su diseño se describe a continuación.
5
DISEÑO DE LA ARQUITECTURA
El
diseño
de
los
paquetes
que
se
implementarán
están
distribuidos de la siguiente forma:
5.1. DISEÑO DE PAQUETES
Paquete Cliente:
En éste paquete se busca agrupar la implementación del la
interfaz del usuario en la Pocket Pc y los componentes de
comunicación con el Relay.
Paquete de Tipos:
Se busca mantener las interfaces de los componentes que crean
la funcionalidad del API con el fin de mantener una relación de
estos, sin crear dependencias directas.
Paquete de Servicios:
Agrupa los servicios necesarios para crear una red P2P, además
mantiene los servicios que entrelazan la aplicación encapsulados
en Aspectos.
Paquete de Índices
Contiene la implementación del Servidor de índices, basado en
un patrón Observer con el fin de desacoplar los clientes del
servidor.
Paquete de comunicaciones
Establece las conexiones directas utilizando el protocolo TCP,
permitiendo una comunicación P2P y la comunicación con el
Servidor de Índices.
5.2. Paquete Cliente:
Paquete Relay
Reside la lógica del Relay basado en el Patrón Proxy, ya que el
Relay hace las veces de un punto en la Red P2P.
Paquete GUI
Representa la lógica que reside en la Pocket Pc y el conjunto de
herramientas para implementar una aplicación sobre el API.
5.3. Paquete Índices
IServidorIndices
Servi dorI ndices
-iPuntosVector:Vector
+attach:void
+detach:void
+inform:void
+iPuntos:Enumeration
Basado en el concepto de un patrón Observer, el servidor de
índices mantiene una lista de los puntos que tiene conectados
facilitando las notificaciones de eventos en el servidor a un bajo
acoplamiento.
5.4. Paquete Comunicaciones
Cliente TCP establece una comunicación P2P con otros puntos de
la Red a través del Relay; mientras que ServidorTCP lanza un
hilo, representado por la clase ServidorHiloTCP, que atiende los
llamados de los clientes en el servidor de índices.
5.5. Paquete de Tipos
Posee las interfaces de las clases más importantes de la
implementación,
manteniendo
una
relación
sin
crear
dependencias. Estas clases modelan el comportamiento del API y
la manera de cómo se deben implementar las aplicaciones.
5.6. Paquete de Servicios
Los Servicios 1,2 y 3 son los servicios básicos que debe tener la
mayoría
de
las
aplicaciones
p2p,
estos
servicios
serán
mencionados en el punto 6 de este documento.
Mientras que los Aspectos, que residen el Paquete de Aspectos,
son considerados como servicios y dan valor agregado al API,
algunos de los aspectos que se planean implementar son
mencionados en el punto 7.
6
SERVICIOS A IMPLEMENTAR

Publicación de Puntos Ante el Servidor de Índices

Búsqueda de Servicios en la Red P2P

Envío de Mensajes y transferencia de datos
o Envío de Archivos
o Envío de Audio
7
OTROS SERVICIOS

Servicios de Seguridad

Servicios de Encripción de Datos

Auditoria de Mensajes
8
REFERENCIAS
[KINN]
Thomas C. Kinnear, James R. Taylor. “Investigación de
Mercados 5ª Edición”. McGraw Hill. Colombia 1998
[GAMM] Gamma, Erich. “Design patterns : elements of reusable object
- oriented software”. Addison - Wesley professional computing
series. Reading, Massachusetts, 1995.
[OLSN]
Olson, Lance. “.NET P2P: Writing Peer-to-Peer Networked Apps
with the Microsoft .NET Framework”. The Microsoft Journal for
Developers (MSDN Magazine). Febrero 2001.
[ADDM] An
add-in
Studio.NET
for
Aspect
Tomado
Oriented
Programming
Noviembre
7
de
in
Visual
2004.
http://www.codeproject.com/macro/AspectOrientedVSNet.asp?