Modulo Distribuido de Subasta Java sobre CORBA de Tiempo Real
P. Basanta-Val’, M. Garcia-Valls, H. Morillas Rodrigo y J. Cano-Romero
Departamento de igenteia Telemaica, Cvedad Carls It de Mout, ava Onversidad 30, 28911, Leganés) Madrid, Espasa
Resumen
Eluso de inftaestructuras middleware que permitan intercomunicar diferentes nodos de un sistema puede aliviar aspectos importantes
relacionados con al coste de desarrollo y mantenimiento de dichos sistemas en entomos flesibles. Ea este coatexto el articulo presenta
‘una arquitectura desatrollada dentro del contexto de los sistemas de subasta distribuidos que tienen cierto: requistos de tiempo real que
than de ser satisfechos. Dicha arquitectura implementa un sistema de puja doble (CDA) para un sistema de tiempo real industries. El
articulo presenta tanto la arquitectura del sistema con sus diferentes actores asi como wa evaluacién en tna plataforma real utilizando
middleware de tiempo real ya existente. Copyright © 2012 CEA. Publicado por Elsevier Espaiia, SL. Todos los derecios reservados.
Palabras Clave:
Sistema de Subasta, Informatica Industrial, Middleware, Tiempo Real, RT-CORBA, Real-time Java
1. Introduccion
El advenimiento de Intemet a principios de los noventa dio
lugar a mievor modelos de negocio que antes no eran posibles.
Las baizeras sicas y temporales acociadas a los procesos de
negocio labituales se Vinieton abajo, y uno de los ejemplos mas
‘earactersticas de esta nueva economia fueron los portales de
subastas online (como por ejemplo eBay.com). E1 modelo es
sencillo pero novedoso: el portal se encarga de poner en contacto
‘a particulares y empresas y de gestionar las subastas. Son dichos
clientes (particulares y empresas) los que poseen los bienes y
servicios. El sitio web sélo se encarga de la gestidn, no realiza
rninguna accién fisica sobre el intercambio de productos: un
modelo de negocio puramente virmal
‘La mayor parte de los subastadores que existen fancionan de
forma elecirénica cerrando operaciones automiticamente, cuando
se dan las condiciones necesarias para ello, como acurte cuando el
‘comprador y el vendedor ofrecen el mismo precio (Cliff, 2003).
‘Ota caracieristicn que tienen es requerir un cierto tiempo
respuesta maximo en el proceso de subasta desde el momento en
‘al que se da Ia orden hasta el momento en que ésta se realize,
Existe también la posibilidad de que dichos sistemas offezcan
diferentes tipos de servicio con diferentes calidades de servicio
segiin la cantiad pagada al proveedor del servicio.
El tema de la creacién de subastadores ha suscitado interés
investigador tanto desde el punto de vista arquitectinico, en
relaci6n con las diferentes arquitecturas existentes, como a ls hora
dde soportar dichos sistemas. Asi, Ia literatura existente cubre tanto
aspectos tecnoldgicos como puede ser una implementaciéa
(Aleksy, Korthaus, Sehader, 2001) mediante middleware CORBA
* Autor de coesponencin
Corres elec dnicos. pbseata@stucSm.es (Pablo Basata Va),
savallsdstucimes (Mansel Gaia Val).
‘hector28933 Gmail com ctor Moras Rode)
nuesm.as lto Angel Cano Romxo)
URL: ww. te uc3m.es/draquien/
(Siegel, 1999) como otros mis teéricos relacionados con los
modelos formales que implementan los diferentes algoritmos de
subasta existentes en las plataformas actuales (Vytelingum, 2006),
(Slemperes, 1999),
Dichos subastadores electrénicos, bien conocidos en el nmando
Internet y con arquitecturas y estrategias bien definidas, tienen
también cabida en el sistema informatico de una planta industrial
(Bussmann and Schild, 2000). La suibasta se puede incorporar
como un médulo avanzado relacionado con la gestion de recursos
y facturacién realizada en una planta (Figura 1), De esta manera
se puede realizar por un proceso de subasta tanto la provisién de
bienes como la propia venta de los productos producides de forma
puramente electronica. La integracion de este médulo de subasta
permite una gestion mas agil y eficiente de la produccion, que
‘puede ser regulada, a partir de fujos de oferta y demanda surgidos
el subastadar. Tanto proveedores como demandantes pueden
tener un acceso agil y actualizado a las diferentes ofertas
existentes en el enfomo industrial La subasta también se puede
aplicar sobre el propio sistema de preduccién que negocia los
diferentes elementos de la linea de produccién. La aplicacién a un
entorno industrial donde existen plazos que han de ser cumplidos
fuerza a que los tiempos del subastador estén en el rango de los
ppocas milisegundos a los pocos segundos (dependiendo del
elemento subastado) [cestor ae Sistema inaustiat
t
Figua 1 Ineprcion de fa tecnctosin de subasts deato de wn software de
sss indurtal de orden euperee
SUBASTADOR
En este marco de la coutribucién realizada por este articulo es
Ja de proveer ua subastador sencillo e integrable deatto del
fentorno industrial distribuido. La contribueién se ceatra en los
aspectos de disetio e implementacién del subastador. En el bajo
‘nivel esta tanto en la eleccidn ua algoritmo de subasia como en $0
posterior implementacién en una plataforma de tiempo real. El
‘evaluarlo va a permitir decidir sobre al readimiento esperable de
1a plataforma escogica en la implementacisn,
En la implementacion se escoge la tecnologia RT-CORBA,
(Schmidt and Kuhns, 2000) y en especial el middleware Java
RTZen (Raman et a. 2005) para realizar dicha arquiteetura. La
‘ventaja que tiene adherisse al estindar RT-CORBA es la de
isthutar de una serie de mecanismos genéricos que permiten
controlar de forma esténdar Ia calidad de servicio. Por iltimo,
utilizar Java permite reducir (Phipps, 1999) los tiempos de
desaurollo de os algoritmnos de subasta.
Los resultados de readimiento descritos en este artculo (sobre
‘RTZen) soa también interesantes para Is comunidad investigadora
‘Java de tiempo real (Basanta-Val and Anderson, 2012) pues les
permite ver el rendimiento que RTZen puede offecer a
aplicaciones distibuidas. Las técnicas ullizadas son también de
utilidad para mejorar arquitecturas de subasta ya descritas con
nuevas caracteristicas de tiempo real. Una de elas es la ya
mencionada arquitectura para Ia realizacién de subastas en
CORBA (Aleksy, Korthaus, Schader, 2001). La incorporacion de
las t2euicas descritas en este articulo dentro de dicha arquitectura
ppermitiza ua mayor control sobre los recursos empleados en ns
‘Comunicaciones extremo a exiremo, y puede mejorar sus tlempos
de respuesta,
EL resto del articulo se organiza tal y como sigue. La Seccién 2
introduce el modelo de subasta electronica de forma general.
Dicho modelo sera la base sobre la cual se articular la Seccién 3
‘que aborda el diseio de alto nivel del subastador. Dicho diseio se
‘complementa en la Seccién 4 con el modelo middleware que se ha
‘elegido y la estructura de la base de datos empleada. La Seccidn §
se refiere a su despliegue en un entorno seal y los resultados
‘obtenidos de su evaluaeisa. La Seeciéa 6 estudia la aplicacion de
‘otros modelos middleware alternatives al modelo de subasta
propuesto. Finalmente, la Seccion 7 concluye y expone nuestro
trabajo en curso referent a dicho sistema de subasta,
2. Lasubasta
En un sentido meramente abstacto una subasta es ua
Imecanismo para la interaccién comercial (Klemperer, 1999; Cliff,
2003). La clave se encuentra en el matiz que introduce la palabra
interaccién, ya que conlleva que las partes implicadas tienen que
ccomunicarse de alguna forma para llegar a un acuerdo comercial.
Esta interaccion se especifica mediante tres aspectos distintas
como son: (1) las seglas de intercambio entte las pate, las (2)
estrategias de los participantes y (3) las reglas de finalizacion de la
subasta. Las reglas de intereambio se tienen que acordar antes del
inicio de In subasta, y a lo largo de ésta, los participantes van
‘modificando su estrategia, y finalmente las reglas de finalizacién
determinan cuando termina la subasta
‘Una de las tipologins mis comunes a la hora de elasificar los
‘pos de subastas es segin qué participantes en la subasta soa los
autorizadas a modificar sus ofertas apareciendo la subasta
‘ascendente o inglesa, Ia descendente o holandesa y la subasta
continua, En la subasta inglesa, los compradores modifican sus
ofertas al alza por un objeto hasta que el resto de compradores se
retira, En ln subasta holandesa, el vendedor va reduciendo el
precio inicial pedido hasta que un comprador detiene la puja y
acepta la oferta. Y por timo en la continua doble, los vendedores
y compradores varian el valor de su oferta 0 puja
espectivamente, hasta que ambas coavergen y se realza la Venta,
Tipicamente ésta whiima se usa en mereados financieras o de
aterias primas. En el mundo anglosajén se conoce como
subastas CDA (Continuous Double Auction) (Vytelinzum, 2006),
Las subastas CDA son las que van a centrar el interés del
modelo desarrollado, ya que son los clientes del sistema
(vendedores y compradores) los que definen el comportamiento
el sistema en si, mientras que el sistema central que administra
Jas transaccioues (ofertas acepiadas), se limita a registrar euando
una oferta de compra y una oferta de venta cuadran y se cierra un
twato, y ese es el tipo de comportamiento que se est buscando en
este trabajo,
Para comprender mejor eémo funciona un sistema de subasta
CDA, se puede ver la siguiente secuencia de ofertas y pujas
(Tabla 1):
Tabla 1: aso dacor ca ua masta CDA,
Paso _| Oferta vendedor—
7 Toe
z i200
3 1000
z S508
En el tiltimo paso, después de que el vendedor fuera rebajando
Jn cantidad que pedia y el comprador fuera aumentando el precio
que estaba dispuesio a pagar, se llegé a un momento de
convergencia y se cetré la transaction.
2.1 Marco Histérico de los Subasiadores
Los primeros sistemas de subastas en Internet pueden
encontrarse en sistemas por correo clectrénico y grupos de
noticias alrededor de 1988 (Cliff, 2003). Con el desarrollo de
Internet a principios de los 90 empezaron a surgir formas mas
sofisticadas de subastas online, Al principio simplemente se
publicaban los listados de productos con informacion mmltimedia
alladida en una pigina web y las subastas se seguian realizando
jpor correo electrSaico. El siguiente paso fue el use de formularios
ppara recolectar las ofertas
Ebay surgié en 1995 y fue uno de los primeros y mas
conocides sitios de subastas en Internet. y poco tiempo después
surgieron competidares como Ubi, Onsale y Z-auctioas. Se pudo
‘ver por aquella época como se empezaba a dividir el mercado de
Jas subastas en linea en fnacion dal tipo de participantes
En el terreno de las subastas entre empresas, una empresa
como Fastpaits.com ya offecia servicios de subasias basades en boletines en el allo 1991 y en el alo 1996 ya cred un sitio web. A
Ja vez que se incrementabs la popularidad de los sitios web que
gestionaban subastas, surgieron compaiias de software que
foffecian productos para que los clientes montaran sus propios
servicios de subasias. Inicialmente fueron compadias
independieates como Opeusite, Tradiug Dynamics, Moai o los ya
resefiadas FreeMarkets, que surgieron a mediados de los 90.
‘Con el paso del tiempo las grandes compadias de software para
‘empresas empezaron a adguirir algunas de las empresas
independientes meucionadas y otras a crear sus propias
hheramientas de subastas. El primer camino fue tomado por
ejemplo por Siebel (ahora parte de Oracle) cuando adquirié
Opensite y Ariba adquirié Trading Dynamics. En lo que respeta
IBM, en 1998 ya empezé a trabajar en su propia heiramienta de
subastas,
Por otro lado, también hay que resear los sistemas online de
ssubastas eonstruides sobre redes propias al margen de la WWW,
tipicamente como una extensién de los sistemas bursitiles, como
fe por ejemplo la creacién por parte del mercado de valores
americano NASDAQ de! sistema Small Order Execution System,
2.2 Estrategias de Subasta CDA
‘A la hora de modelar el comportamiento de los compradores y
los vendedores hay que tener en cuenta dicho flujo contigo de
informacién y realizar suposiciones que petmitan tomar
Cases deus relacionados cn e acceso a uaa subasta
4.2 Disesio Relacionado con la Inictalizacién del Sistema de
Subasta
Los objetos remotos definidos en el apartada anterior
interaccionan entre si para controlar el acceso de los clientes all
sistema de subastas. A uavs del objeto intermediatio se realiza la
autenticacién de los clientes y el acceso de éstos a las diferentes
‘etiquetas por las que pueden pujae. En segundo plano, a través del
almacenamiento persistente que offece la base de datos, se
garantiza In coordimcidn entre el proceso de autenticacion de
clientes y a conexidn a una de las etiquetas, asi como la
descouexida. Como se puede ver en la Figura 2, el intermediario
tiene cuatro casos dé uso, uno para crear un objeto comerciante
(autenticéndolo) ¥ otros tres para mauejar el acceso a las
cetiquetas: biisqueda, conexidn y desconexton.
El proceso completo de iniializacién comprende los pasos de
‘ereacion de referencia del intermediario y de referencia del
‘comerciante tal y como se muestra en la Figura 3 y la Figura 4. En
estos diagramas se ve el ciclo completo de la gestion de las
cetiquetas que va desde 1a busqueda de la etiqueta eu la base de
datos hasta Ja conexién con la etiqueta, Dicha conexion es
rnecesaria para poder realizar pujas, ofertas y consultas sobre la
cetiqueta, la cual simboliza el item por el que se quiere pujar
Finalmente el cliente también puede eliminar la etiqueta lo que
‘anula su utlizacion en el sistema de subasta,
En estos hay que fener en cuenta una serie de sestricciones de
bajo nivel relativas a lo que es el proceso de autenticacién:
= Sila autenticacién es exitosa, se crear un objeto de servidor
sepresentando la identicad del comerciante, esto es, el cliente
que se ha couectado al sistema,
= Allahora de buscar etiquetas no se erean objetos de servider,
sino que simplemente se realiza una busqueda en base de
datos.
= La conexién con una etiqueta supoue buscar el abjeto de
servidor que 1o representa y si no existe ctear dicho objeto
“Tras ello, se introducira la identicad del comerciante en la
lista de ‘clientes autorizados a realizar pujas sobre esa
etiqueta
= La desconexién elimina la asoclaciin ene el objeto
comesciante el objeto etiqueta, eliminaudo ésta si no existen
amis comerciantes conectados.
coma
1
t
It
1
1
1
i
1
'
i
1
1
1
i,
Figura 4: Detalle eno de a inicialinein del cle yl crete del objeto
intennediania
3.3 Diseno Relacionado con el Proceso de Subasta
Una vez inicializada la conexién al sistema, el cliente puede
participar en subastas, siguiendo la secuencia de operaciones de subasta que son las que permiten que los diferentes actores puedan
Iegar a acuerdos sobre sus transacciones basadas en etiquetas.
Dichas operaciones nevesarias para participar en una subasta se
reducen a pujas y consulas de ventas y de compras, tal y como
Listastrings
‘SYpeder sequenceciong> Liscaine:
4 interfaces
Snterface intersadiario
‘tring crearCowerclante():
CiSeasertng buscaretaquetac
{In Listastring palabrasclave)
raises Cojetalogeiatecxception):
string conectaretiqueta(
{strane toro
sonarecorenesanes,
In string id seston)
ralses csjeraionxteteexception):
void eliminaretiqueta(in string nonbreetiquete,
ir string ia seston)
Palses (Objetaobcistetxception):
‘String eutenticar(in string sonbre,tn stetog possuond)
Wraisen( Autenticerionésception
‘Tong consultsconpra(sn string Se seston);
ong consultaVenta(sn string id-zesion);,
tring pigacampralin long #9, string 22 seston, in long
‘io oit)
ratses (
PuaProhdbida,pufatrautictente,Pufstaptrace ):
String pujaventa(in long’ precio,in string seston, ta
tong tise_ot)
raises (
Pujabrontoiaa,pujatnsutictente,Pujecepinace
mantenimiento en sistemas abieitos con diferentes tipos de
clientes.
‘Como se puede observar, se tiene un modelo cliente-servidor,
que se conminica mediante el protocolo IOP, que posibilita la
propagacisn invocacioues de objetos remotos CORBA a través de
TcPR.
Px [a uansaccen
¥
Fat [ic-comerciante Px [i ataueta
pasewora eeserocion
‘Figua 9: Modeiode mformacibn pesstnt:esretura dela base de datos
k
Figura & lnverices DE
4.3 Gestién de la Persistencia y Modelo de la Base de Datos
La informacion petsistente, que se necesita para mantener a
arquitectura, se reduce a mantener la informacién relativa a los
ccomerciantes, la informacion que describe una etiqueta y el
registro de Ins transacciones realizadas, al y como se muestra en
Ja Figura 9. Hay por tanto tres tables: una para almacenar
‘wansacciones que almacena el valor de los intervinleates en la
‘operacion: otza para identifica a los comerciantes con su clave: y
‘una fercera que describe una etiqueta con ua nombre.
Dichas tablas se relacionan mediante claves foraneas que
permiten a la transaccién mantener una referencia con el
‘comerciante y con la stiqueta
4.4 Despliegue de la Aplicacién de Subasta
‘Adams de las interfaces de los objetos CORBA y el modelo
‘de datos persistente, también es necesario tener una idea de la
localizaciéa fisica de los distintos elementos de la aplieacion, que
se exponen en el diagrama de despliegue de la Figura 10. Este tipo
de despliegue coincide con los utilizados en aplicaciones
‘empresariales donde la légica del cliente es ligera y se reduce
tenuas de presentacion y donde casi toda la logica de negocio esta
‘en al servider, lo que minimiza los costes de desarrollo y
oa = A
I | ——_
‘ ‘igata ©]
en)
—_
Figura 10: Despliepue tipico de la aquitcrra de subastas,
‘Ademés se pueden ver los archivos de log que van registrando
Jn actividad del servidor, el cliente y la base de datos. Dicha base
4e datos almacena la informacién persistente del servidor, en sus
os implementaciones posibles (HSQLDB y Apache Deiby)
comunicada con el servidor mediante wa driver JDBC con el
servider.
Por titimo, destacar la interfaz con el usuario en el lado del
cliente, la cual permite que éste interaccions de forma adecuada
con el sistema mediante un broker local que sitve de puente entre
el lado cliente y al Indo servider.
5. Evaluacion
A la hora de evaluar el rendimiento del sistema de subastas
propuesto hay ua aspecto fundamental a considerar: el
readimiento de las invocaciones cliente-servidor, definidas éstas ‘como tiempo que wanscurre desde que se envia la peticién hasta
‘que se recibe la respuesta, Pero también es interesante obtener la
funcién de distribucién de probabilidades que muestre cémo se
reparten dichos valores en Jos casos peoresiiejores y promedio,
‘Oto aspecto importante a considerar en la evaluacién empitica
cconsiste en In identificacia, en los escenarios de pruebas, de
‘aquellas variables que pueden afectar a los resultados y que se
pueden modificar de forma controlada,
Los experimentos realizados tienen por tanto como abjetivo
‘comprobar el rendimiento de la aplicacién en funcién de los
sities parémetros
= Retardo introducio por Ia red de comunicaciones entre los
clientes y servidores.
+ Efecto del paralelismo y la ausencia de éste en la ejecucién
de la aplicacion.
= Diferencias de rendimiento entce las distinias maquinas
virtuales de Java disponibles en el mercado que resultan
compatibles con RTZea,
‘Sobre una estructura bisiea donde hay un cliente y un servidor
se instala cliente que realiza pujas (compra/venta) en una base de
datos empotrada en memoria, donde existe un mimero bajo de
uns, Ambos procesos (compra/venta) offecen rendimientos
similares (en tiempo de respuesta). Sobre esta infraestructura
basica se varian tres parametres
~ La prioridad a la que ejecuta cada cliente (que puede ser
1000 © 2000) y el niimero de clientes. El objetivo es ver
que el comportamiento obtenide se corresponde con el
comportamiento expulsivo tipico de ua sistema de tiempo
real
= Latopologia de sistema que puede estar desplegado en un
linico procesador 0 en un sistema distribuido con una re.
~ _ Laméguina virtual utlizada durante la ejecucion.
La generacion de peticiones se hace con trazas generadas de
‘forma automsética mediante scripts
5.1 Pila cle Componentes Software y Red Uti
Comumicacion
ida para la
La aplicacién se instalara sobre una pila de componentes, cuya
cconfiguracion definiré nuestro escenario de pruebas, tal y como se
puede ver en la Figura 11. Dicha pila tiene la méquina sobre la
‘que se instala sistema Linux (el recomendado por RTZen) y una
‘méquiaa virtual Java com soporte parcial (offecido por RTZen) &
RTSI Bollella G. et al. 2001). Encima de esta maquina virtual
festa RTZen, elemento clave sobre al que se apoya el sistema de
subastas,
En esta arquitectura uno de los elementos con los que se ha
jvendo son las diferentes maquinas virtwales de Java que dan
soporte a RTZen. Las utilizadas en los experimentos se detallan en
Ja Tabla 2. Las tres mquinas: la de IBM, Sua y Oracle (JRMC),
funciouan correctamente cuando son utllizadas por RTZen para el
“despliegue de aplicaciones
Teniendo en cuenta estas méquinas virales, se define ua
escenario distribuido con diferentes maquinas virtuales. En este
‘caso la infraestructura de red utilizada es una red Ethemet (Figura
12), El sistema se encuentra virtualizado, lo que permite asignar
‘una tarea a un tinico micleo para los equipos que usen un sistema
multicore, Las méquinas utilizadas son Tatel para los Xeon 7300
(a4 GHz y con 8 MB de cache) y la sed wtiizada de | Gigabit
Sistens de Subastes
| Sistons operative I
Maquina
Figue 11 Pla software de despliegue de in arquitectura de subasas|
“abla 2: Maquinas Vistas Uubizades
Te | ae SE viraal ae
sun SoaCTh) SE Rules ava Eee
putld 1e.e 17-bos
oracle] Seva Th) Se Runtime WEE HoT
put 116.6 11-062 ferts
7a Java(T) SE Ranting Tait 73-7
Envaronnent ule 204 22RE 1.6.0
bute petazeaees-
Figura 12 Escenaio de prucbas wlizado
Para aislar el compottamiento de estas dos variables frente a
los retardos introducidos por la lectura y escritura ea disco, se
utlizd un almacenamiesto en wna cabina de discos SAN, que
utiliza fibra éptica como medio de transmisiéa y tiene una cache
de 32 GB que amortigua por completo los posibles retardos por ‘escritura en disco al encolar todas las peticiones de escritura en
memoria RAM.
5.2 Tiempo de Respuesta Extremo a Extremo
‘Auague pueda parzcer que la eleceién de la maquina virtual
Java puede fener un impacto bajo o medio en el rendimieato final,
‘esto no es as. Elelegir una v otra infaestructura tiene un impacto
S-ar putea să vă placă și
- Circuitos de Control y Motores Electricos Parte 2Document35 paginiCircuitos de Control y Motores Electricos Parte 2armandojr1991100% (13)
- Go PDocument29 paginiGo PJose Luis EspinosaÎncă nu există evaluări
- Procesamiento MultimediaDocument13 paginiProcesamiento MultimediaJose Luis EspinosaÎncă nu există evaluări
- Transmision de PaquetesDocument10 paginiTransmision de PaquetesJose Luis EspinosaÎncă nu există evaluări
- Trabajo 1 Comunicaciones OpticasDocument2 paginiTrabajo 1 Comunicaciones OpticasJose Luis EspinosaÎncă nu există evaluări
- MigracionDocument1 paginăMigracionJose Luis EspinosaÎncă nu există evaluări
- Implementacion de Grangas de ServidoresDocument403 paginiImplementacion de Grangas de ServidoresJuan SanchezÎncă nu există evaluări
- Buenas Practicas en Motores de CADocument16 paginiBuenas Practicas en Motores de CAJorge Adalberto Barreras GarciaÎncă nu există evaluări
- MigracionDocument2 paginiMigracionJose Luis EspinosaÎncă nu există evaluări
- MigracionDocument2 paginiMigracionJose Luis EspinosaÎncă nu există evaluări
- Experimento de QuimicaDocument1 paginăExperimento de QuimicaJose Luis EspinosaÎncă nu există evaluări
- MCCSS Pendientes 1 Tema 03 Numeros RealesDocument2 paginiMCCSS Pendientes 1 Tema 03 Numeros RealesJose Luis EspinosaÎncă nu există evaluări
- Hayt 9Document32 paginiHayt 9Jose Luis EspinosaÎncă nu există evaluări
- Hayt Capitulo 11Document63 paginiHayt Capitulo 11Jose Luis Espinosa40% (5)
- Espiritu y EspiritualidadDocument9 paginiEspiritu y EspiritualidadJose Luis EspinosaÎncă nu există evaluări
- Hayt 8Document32 paginiHayt 8Jose Luis EspinosaÎncă nu există evaluări
- Herramientas de Instalaciones AlesDocument2 paginiHerramientas de Instalaciones AlesJose Luis EspinosaÎncă nu există evaluări
