Corb Aaaaa Sense I

TCNICASDEDESARROLLODEAPLICACIONES
DISTRIBUIDASTOLERANTESAFALLOSSOBRE
ARQUITECTURASCORBAYJAVARMI
Memoriaquepresentaparaoptaralgradode
DoctorenInformtica
LuisMiguelPeaCabaas
Dirigidaporeldoctor
JuanPavnMestras
DepartamentodeSistemasInformticosyProgramacin
FacultaddeInformtica
UniversidadComplutensedeMadrid
Mayo,2002
iii
Silopuedessoar,lopuedeshacer.
-WaltDisney
Oneringtorulethemall,
Oneringtofindthem,
Oneringtobringthemall
andintheDarknessbindthem
-J.R.R.Tolkien
(ejemplodediseocentralizado,
notoleranteafallos)
Atodoslosqueosheconocidoduranteestoslargosaosdedoctorado.Lolargoha
hecho,almenos,queseismuchos.Graciasporvuestracompaayapoyo.Atodos
lossitiosdondehevividoydisfrutadomientrasSenseiibaevolucionando.Enespecial,
porlosrecuerdosquemetraenenrelacinconestaTesis,Brujas,Amberes,Dublin,y
untrayectoFrankfurt-Stuttgarttantasvecesrecorrido.
iv
v
Resumen
Las tcnicas de tolerancia a fallos en arquitecturas distribuidas cliente/servidor

(como CORBA, Java RMI o Microsoft DCOM), que a nivel software se implementan
principalmentemediantelareplicacindeservidoresparaocultarfallosindividuales,
presentanunainterfazdemuybajonivelquehacendifcillaimplementacindelos
servicios tolerantes a fallos. El rendimientodeestossistemas,quedebenactualizar
en cada operacin dos o ms servidores en lugar de slo uno, y cuya actualizacin
debe realizarse con una sincronizacin muy cuidada para evitar inconsistencias, es
sensiblemente inferior al de los sistemas no tolerantes a fallos. Por esta razn, las
principaleslneasdeinvestigacinenestareahanbuscadolasformasdeoptimizar
esascomunicacionesparaobtenersistemasconunrendimientoprctico.
Sinembargo,otraslneasdeinvestigacinsehancentradoenelestudiodepatrones
deimplementacinquefacilitenelempleodelastcnicassubyacentesdetolerancia
a fallos. El sistema propuesto en esta tesis, Sensei, se encuentra en este campo,
estudiando cmo aplicar estas tcnicas a grupos de objetos y cmo definir una
interfaz de alto nivel que permita un cmodo empleo de los modelos de
comunicacionesfiablesentreservidoresreplicados.
Porunaparte,Senseitrataelproblemadelatransferenciadeestadoentrerplicas,
unaspectodelareplicacincubiertoenlateorabsicadesincronavirtualperocon
muy poca cobertura en las implementaciones actuales. Definimos un modelo que
cubre desde los protocolos de bajo nivel especificando los mensajes y los
rendimientos en diversos sistemas, hasta los protocolos de alto nivel especificando
suinterfazenlenguajeIDLdeCORBA.Msimportante,estudiamoslascondiciones
que deben cumplir las aplicaciones para poder emplear los distintos modelos de
transferenciadeestadoycmoafectanalmodelodesincronavirtualsobreelquese
construyenlasaplicacionesreplicadas.
Estos protocolos se implementan parcialmente sobre uno de los sistemas de
comunicaciones fiables ms conocidos, Ensemble. No obstante, hemos desarrollado
tambin un sistema de comunicaciones fiables propio, SenseiGMS, persiguiendo
definir una interfaz general, comn a los modelos actualmente existentes, sobre la
queimplementamostotalmentelosprotocolosdesarrollados.
Una vez resuelta la transferencia de estado, Sensei se centra en los patrones de
comunicacin de alto nivel, que permiten a aplicaciones orientadas a objetos
mantenerse en el mismo nivel de abstraccin al replicar esos objetos. El sistema
tradicional de comunicaciones en los sistemas de comunicaciones fiables entre
rplicas es el intercambio de mensajes entre esas rplicas, mientras que en Sensei
hemos desarrollado una aplicacin, SenseiDomains, que permite factorizar esas
comunicaciones a nivel de componentes que pueden definirse dinmicamente en
dominios,buscndosedeestamaneralaabstraccindeobjetos.
vi
Adems, se observan los patrones ms empleados al disear las aplicaciones con
tolerancia a fallos, implementndolos o soportndolos en la medida de lo posible.
Una aplicacin directa de este soporte de los patrones de implementacin es la
posibilidad de replicar automticamente aplicaciones diseadas inicialmente como
entidades autnomas sin replicacin. Sensei define la forma de migrar esas
aplicaciones para soportar tolerancia a fallos y formas posteriores de optimizar las
comunicaciones entre las rplicas resultantes.Parasoportarlosehadesarrolladola
herramientaSenseiUMA.
Como ejemplo de aplicacin de la metodologa propuesta, se muestra el diseo de
otra de las piezas de la arquitectura, SenseiGMNS, servicio de gestin de grupos
cuyoscomponentesestnreplicados,asuvez,sobreSensei.
Palabrasclave
Sistemas distribuidos, CORBA, JavaRMI, Tolerancia a Fallos, Replicacin de
Objetos,TransferenciadeEstado,Comunicacionesengrupo.
vii
Summary
Fault Tolerance software techniques for distributed client/server architectures (like

CORBA, JavaRMI or Microsoft DCOM) are usually based on the replication of the
serverstohidesinglefailures.However,thesetechniquesworkatalowlevel,making
difficulttheimplementationoffaulttolerantservices.Thesesystemsmustupdateon
eachrequesttwoormoreserversinsteadofjustone,andthemultipleupdatesmust
be carefully synchronized to avoid inconsistencies. As a result, the performance on
thosesystemsisconsiderablyworsethantheequivalentnonfaulttolerantcase.This
is the reason why the main research efforts on this area have been focused on the
optimization of the communications between replicas to obtain systems with a
practicalperformance.
Nevertheless, other line of work has taken a different approach, focusing on the
implementation patterns that facilitate the use of thefaulttoleranttechniques.The
system proposed in this Thesis, Sensei, belongs to this second area, studying the
applicationofthosetechniquestogroupsofobjectsandthedefinitionofahighlevel
interfacetofacilitatetheuseofthereliablecommunicationmodels.
Ononeside,Senseiaddressestheproblemofthestatetransferbetweenreplicas,an
aspect of the replication that, despite beingcoveredbythevirtualsynchrony model,
has usually a poor coverage on current implementations of thismodel.Wedefinea
model to solve this issue, which addresses low level protocols, specifying the
messages and the performance on a variety of systems, and high level protocols,
defining their interface on CORBA IDL. What is more important, we study the
conditionsthattheapplicationsmustholdinordertousethedifferentstatetransfer
models,andhowdotheyaffecttothevirtualsynchronymodel.
These protocols are partially implemented on top of one well-known group
communicationsystem,Ensemble.Nevertheless,wehavedevelopedaswellourown
reliablegroupcommunicationsystem,SenseiGMS,withagenericinterface,common
totheexistingones,andtheprotocolsarecompletelyimplementedoverit.
Once the state transfer issue is solved, Sensei focuses on the communication
patterns that happenathighlevel,whichallowobject-orientedapplicationstokeep
onthesameabstractionlevelwhenthoseobjectsarereplicated.Thebasictraditional
communication entity on reliable group systems is the message, and replicas must
communicateamongthemselvesusingthislowlevelmechanism.InSensei,wehave
developedanapplication,SenseiDomains,thatfactorizesthosecommunicationsinto
component interactions, components that can be dynamically defined, offering a
standardobjectorientationabstraction.
Additionally, we have studied the design process of fault tolerant applications,
catchingthemostusualimplementationpatterns,inordertoimplementorsupport
them. A direct benefit of this support is the possibility to automatically replicate
applications that have been initially designed as standalone. Sensei defines how to
viii
migrate those applications to have fault tolerance, and how to optimize afterwards
thecommunicationsbetweenthecreatedreplicas.SenseiUMAisthetooldesignedto
supportthismigration.
As an example of the proposed methodology, we show the design and
implementation of one of the architectural elements in Sensei, called SenseiGMNS.
This is a group membership service that is itself replicated following the design
principlesandwiththesupportofSenseiDomains.
Keywords
Distributed systems, CORBA, JavaRMI, Fault Tolerance, Object Replication, State
Transfer,GroupCommunications.
ix
NDICE
CAPTULO1-INTRODUCCIN.......................................................................................... 1
CAPTULO2-SISTEMASDISTRIBUIDOS ........................................................................ 7
2.1.MODELOSDISTRIBUIDOS................................................................................................... 8
2.2.SOCKETS .......................................................................................................................... 9
2.3.RPCLLAMADASAPROCEDIMIENTOSREMOTOS ........................................................... 10
2.4.OBJETOSDISTRIBUIDOS................................................................................................... 11
2.5.TENDENCIASACTUALES.................................................................................................. 14
2.6.CONCLUSIONES .............................................................................................................. 15
CAPTULO3-SISTEMASDISTRIBUIDOSFIABLES..................................................... 17
3.1.FIABILIDAD .................................................................................................................... 17
3.1.1.Toleranciaafallos .................................................................................................. 18
3.1.2.Sistemasdistribuidos............................................................................................... 19
3.1.3.Deteccindefallos.................................................................................................. 20
3.1.4.Gruposdecomponentes .......................................................................................... 21
3.1.5.Comunicacionesfiables........................................................................................... 22
3.2.SERVICIODEMIEMBROSDEGRUPO(GMS)...................................................................... 25
3.3.SINCRONAVIRTUAL....................................................................................................... 27
3.4.OBSERVABILIDADDELGRUPO......................................................................................... 28
3.4.1.Comunicacionesexternasdelgrupo........................................................................ 28
3.4.2.Replicacin ............................................................................................................. 30
CAPTULO4-SISTEMASDECOMUNICACIONESENGRUPO.................................. 33
4.1.SISTEMASDECOMUNICACIONESENGRUPO ..................................................................... 33
4.1.1.Amoeba ................................................................................................................... 34
4.1.2.Arjuna ..................................................................................................................... 34
4.1.3.Bast ......................................................................................................................... 35
4.1.4.UniversidaddeCornell:Isis/Horus/Ensemble/Spinglass................................... 36
4.1.5.Cactus ..................................................................................................................... 37
4.1.6.Electra .................................................................................................................... 37
4.1.7.Ibus/MessageBus................................................................................................... 38
4.1.8.JavaGroups............................................................................................................. 39
4.1.9.JGroup.................................................................................................................... 40
4.1.10.Nile ....................................................................................................................... 41
4.1.11.Phoenix ................................................................................................................. 41
4.1.12.RMP...................................................................................................................... 42
4.1.13.Spread................................................................................................................... 42
4.1.14.Totem.................................................................................................................... 43
4.1.15.Transis .................................................................................................................. 44
4.1.16.xAmp ..................................................................................................................... 44
x
4.2.TRANSFERENCIADEESTADOENMAESTRO ....................................................................... 45
4.2.1.Versin0.51............................................................................................................. 45
4.2.2.Versin0.61............................................................................................................. 50
4.3.CORBA.......................................................................................................................... 50
4.4.CONCLUSIONES ............................................................................................................... 54
CAPTULO5-CONDICIONESENLATRANSFERENCIADEESTADO...................... 57
5.1.MODELOYDEFINICIONES ................................................................................................ 60
5.2.REQUISITOSPARALATRANSFERENCIA ............................................................................ 63
5.2.1.Cambiosdevistas .................................................................................................... 66
5.2.2.Transferenciasdeestadosenvariospasos............................................................... 69
5.2.3.Cambiosdevistasentransferenciasenvariospasos ............................................... 71
5.3.ALGORITMODETRANSFERENCIADEESTADO ................................................................... 71
5.4.CONCLUSIONES ............................................................................................................... 72
CAPTULO6-PROTOCOLOSDETRANSFERENCIADEBAJONIVEL..................... 75
6.1.REQUISITOSDELOSPROTOCOLOS.................................................................................... 75
6.2.TRANSFERENCIAPUSH..................................................................................................... 77
6.3.TRANSFERENCIAPULL ..................................................................................................... 79
6.4.TRANSFERENCIAPUSH-ONESTEP ..................................................................................... 80
6.5.COMPARATIVASDEPROTOCOLOS .................................................................................... 80
6.5.1.Protocolospushypush-onestep.............................................................................. 80
6.5.2.Protocolospushypull ............................................................................................. 82
6.6.GMSCONSOPORTEDETRANSFERENCIADEESTADO........................................................ 83
6.7.GRUPOSPARTICIONABLES ............................................................................................... 85
6.8.CONCLUSIONES ............................................................................................................... 86
CAPTULO7-INTERFAZDEAPLICACINDETRANSFERENCIADEESTADO.... 87
7.1.TOLERANCIAAFALLOSENCORBA ................................................................................ 88
7.2.DISEODELAINTERFAZ.................................................................................................. 90
7.2.1.Transferenciasenvariospasos ................................................................................ 90
7.2.2.Cambiosdevistas .................................................................................................... 91
7.2.3.Propiedadesdemiembros........................................................................................ 93
7.2.4.Eleccindelcoordinador......................................................................................... 94
7.2.5.Concurrenciaenlatransferencia............................................................................. 95
7.3.INTERFAZDETRANSFERENCIA......................................................................................... 96
7.3.1.sync_transfer ........................................................................................................... 98
7.3.2.start_transfer ........................................................................................................... 98
7.3.3.get_state .................................................................................................................. 99
7.3.4.set_state................................................................................................................... 99
7.3.5.interrupt_transfer .................................................................................................... 99
7.3.6.continue_transfer................................................................................................... 100
7.3.7.stop_transfer.......................................................................................................... 100
7.4.PROPIEDADESDEMIEMBROS ......................................................................................... 101
xi
7.5.EJEMPLOSDEUSO(USECASES) ...................................................................................... 103
7.5.1.InterfazCheckpointable ........................................................................................ 103
7.5.2.InterfazBasicStateHandler ................................................................................... 103
7.5.3.InterfazStateHandler ............................................................................................ 108
7.6.IMPLEMENTACINSOBREPROTOCOLOSDEBAJONIVEL ................................................. 111
7.7.CONCLUSIONES ............................................................................................................ 112
CAPTULO8-SENSEIGMS .............................................................................................. 115
8.1.DISEO......................................................................................................................... 116
8.1.1.Interfazpblica ..................................................................................................... 117
8.1.2.Interfazprivada..................................................................................................... 121
8.2.ALGORITMODEPASODETESTIGO ................................................................................. 123
8.2.1.Pasodetestigoyestructuraenanillo.................................................................... 124
8.2.2.Deteccindeerrores ............................................................................................. 124
8.2.3.Envodemensajes ................................................................................................. 125
8.2.4.Manejodevistas.................................................................................................... 126
8.2.5.Gestindegrupos ................................................................................................. 128
8.2.6.Protocoloderecuperacindeltestigo................................................................... 129
8.3.USODESENSEIGMS..................................................................................................... 130
8.3.1.Diseodeunservicioreplicado ............................................................................ 130
8.3.2.Implementacin..................................................................................................... 132
8.3.3.Configuracin ....................................................................................................... 136
8.4.VIRTUALNET................................................................................................................ 137
8.5.CONCLUSIONES ............................................................................................................ 139
CAPTULO9-METODOLOGADEDESARROLLO.................................................... 141
9.1.SINCRONIZACINDELARESPUESTA.............................................................................. 143
9.2.TRANSFORMACINDEOPERACIONESENMENSAJES ....................................................... 146
9.3.COMPORTAMIENTONODETERMINISTA.......................................................................... 149
9.4.REPLICACINDECOMPONENTES ................................................................................... 150
9.5.LIBRERASDECOMPONENTESREPLICADOS.................................................................... 152
9.6.SOPORTEDECONCURRENCIA ........................................................................................ 152
9.7.TRANSFERENCIADEESTADO......................................................................................... 155
9.8.GESTINDECOMPONENTESREPLICADOS ...................................................................... 156
9.9.TRANSACCIONES .......................................................................................................... 161
9.9.1.Transaccionesyelmodelodesincronavirtual..................................................... 168
9.10.COMPARACINCONELMODELODECORBA .............................................................. 170
9.11.CONCLUSIONES........................................................................................................... 173
CAPTULO10-SENSEIDOMAINS .................................................................................. 175
10.1.EXCEPCIONES ............................................................................................................. 176
10.2.TRANSFERENCIADEESTADO....................................................................................... 177
10.3.PROPIEDADES ............................................................................................................. 182
10.4.COMPONENTES ........................................................................................................... 185
xii
10.5.MENSAJES................................................................................................................... 188
10.6.CONTROLDECONCURRENCIA...................................................................................... 189
10.7.DOMINIOS ................................................................................................................... 192
10.8.IMPLEMENTACIN....................................................................................................... 198
10.9.CONCLUSIONES ........................................................................................................... 201
CAPTULO11-SENSEIGMNS.......................................................................................... 203
11.1.GESTINBSICADEGRUPOS ....................................................................................... 204
11.2.SERVICIODEDIRECTORIO............................................................................................ 208
11.3.DISEODESENSEIGMNSENCOMPONENTESDINMICOS ............................................ 210
11.3.1.Implementacindeloscomponentes .................................................................... 214
11.3.2.Integracindecomponentes................................................................................. 220
11.3.3.Implementacindelosalgoritmos........................................................................ 222
11.4.CONCLUSIONES ........................................................................................................... 224
CAPTULO12-CONCLUSIONESFINALES................................................................... 227
12.1.APORTACIONESREALIZADAS....................................................................................... 227
12.2.TRABAJOFUTURO........................................................................................................ 231
APNDICEA.ESPECIFICACINCORBADESENSEIGMS........................................ 235
A.1.GROUPMEMBERSHIPSERVICE.IDL................................................................................. 235
A.2.INTERNALSENSEI.IDL ................................................................................................... 236
APNDICEB.ESPECIFICACINCORBADESENSEIDOMAINS .............................. 239
B.1.DOMAINEXCEPTIONS.IDL.............................................................................................. 239
B.2.STATETRANSFER.IDL.................................................................................................... 240
B.3.PROPERTIES.IDL............................................................................................................ 242
B.4.SUBGROUPSHANDLER.IDL ............................................................................................ 243
B.5.DOMAINMESSAGE.IDL.................................................................................................. 245
B.6.CONCURRENCY.IDL ...................................................................................................... 245
B.7.DOMAINGROUPHANDLER.IDL....................................................................................... 246
B.8.INTERNALDOMAINMESSAGES.IDL ................................................................................ 248
APNDICEC.ESPECIFICACINCORBADESENSEIGMNS ..................................... 251
C.1.GROUPMEMBERSHIPNAMINGSERVICE.IDL.................................................................... 251
C.2.MEMBERINFO.IDL......................................................................................................... 253
C.3.SETMEMBERINFO.IDL................................................................................................... 253
C.4.MAPSTRINGSET.IDL ..................................................................................................... 255
C.5.GROUPSCHECKERSTATE.IDL......................................................................................... 257
APNDICED.EJEMPLOSDECOMPONENTESREPLICADOS ................................. 259
D.1.SETMEMBERINFOIMPL.JAVA ........................................................................................ 259
D.2.MAPSTRINGSETIMPL.JAVA........................................................................................... 264
GLOSARIO........................................................................................................................... 271
xiii
BIBLIOGRAFA.................................................................................................................. 273
Introduccin 1
Captulo1-INTRODUCCIN
El enorme crecimiento de Internet durante los ltimos aos supuso la
aparicin de numerosas compaas cuya presencia comercial se limitaba a este
medio, y la necesidad de las compaas tradicionales de ofrecer tambin sus
servicios en la red. Esta modalidad de servicios implica una fuerte dependencia de
esas compaas en Internet y los medios empleados, de tal forma que ataques
cibernticos pueden suponer la cada del servicio y conllevar prdidas econmicas
millonarias.Esteproblemaesmayorcuandoalacadadelservicioseaadelams
importante de prdida de datos, debido, por ejemplo, a la destruccin del medio
fsico empleado para su almacenamiento. Adems de problemas externos, un
servidor puede necesitar tolerar errores ms comunes, comopuedaserunfalloen
el sistema operativo que emplea, o en el ordenadordondeseejecuta,queprovocan
igualmente la prdida del servicio. La solucin genrica a este problema de
tolerancia a fallos es la replicacin de recursos: almacenar los datos en diferentes
localizaciones,geogrficamentedistantes,oduplicarlosservidoresempleados.
El desarrollo de un servicio que se ofrece simultneamente desde diferentes
servidores implica un problema adicional sobre ese servicio, ya que debe resultar
consistentealosclientes,ofreciendoencadamomentoresultadoscoherentesdesde
cualquiera de los servidores. Esta consistenciasuponenormalmenteunanecesidad
de comunicaciones entre los servidores, que deben sincronizar sus accesos y
modificacionesdelosdatos.Elresultadoesunmayorempleoderecursosyunpeor
rendimientoencomparacinconelmismoservidornoreplicado,detalformaquela
mayor disponibilidad del servicio no justifica en muchas ocasiones la prdida de
Introduccin 2
eficiencia.Lasolucinenestecasoeselempleodereplicacionespasivas,dondehay
un nico servidor activo y uno o ms pasivos que slo se activan en caso de cada
del primero. Sin embargo, hay aplicaciones que pueden tolerar esa prdida de
rendimiento y servicios que no pueden soportar la prdida de disponibilidad, por
corta que sea en el caso de replicaciones pasivas, como puede ser el caso de
dispositivosesencialesenunavin.
El diseo de un servidor replicado activamente no supone nicamente el
empleo de comunicaciones entre todas las rplicas, sino un control de esas
comunicaciones que pueden presentar tambin problemas. Existen abundantes
sistemas de comunicaciones en grupo que facilitan esta tarea, primando
generalmente la optimizacin de esas comunicaciones, con un modelo denominado
de sincrona virtual basado en el envo fiabledemensajesmultipunto.Sinembargo,
elbajoniveldeestaaproximacinimplicaundiseodeaplicacionesestructuradoen
mensajes, dificultando el empleo de soluciones de alto nivel, como pueda ser la
reutilizacindecomponentessoftware.
Un servidor replicado es un caso especfico de aplicacindistribuida,paralas
que existen modelos y arquitecturas que soportan paradigmas de programacin
distribuida ms avanzados que ese intercambio directo de mensajes. Ejemplos de
estas arquitecturas son CORBA, Microsoft DCOM o JavaRMI. Precisamente la
arquitectura CORBA se ha visto enriquecida recientemente con la especificacin de
un servicio de tolerancia a fallos soportando replicaciones activa y pasiva. Este
serviciopermitelacreacindeservidoresreplicadosempleandotcnicasdealtonivel
comoseparacindeinterfazeimplementacin,orientacinaobjetos,compatibilidad
de implementaciones sobre plataformas y lenguajes, y soporte de otros servicios
avanzadosquepermitenempleartransacciones,entreotros.
El trabajo sobre el que versa esta tesis comparte dominio con este servicio
CORBAdetoleranciaafallos,yaquesoportaunmodelodereplicacinactivadealto
nivel, especificado a nivel interfaz de objetos. Sin embargo, los modelos de
replicacin son muy diferentes. Sensei [Sensei] se centra en la replicacin activa e
implementa un sistema que soporta JavaRMI adems de CORBA. Por otra parte, la
granularidadenlareplicacinestambinmuydiferente;mientrasCORBA,congran
soporte para replicacin pasiva, debe tomar el servidor completo como unidad de
replicacin, nuestro trabajo se basa en la factorizacin del servidor en varios
componentesquepuedenserreplicados.
El principal objetivo de esta tesis es la integracin del modelo de bajo nivel
tradicionalmente empleado para el desarrollo de aplicaciones replicadas con los
modelos de alto nivel empleados actualmente en el diseo e implementacin de
aplicaciones distribuidas, aportando una metodologa que facilite la replicacin
activadeservidores.Elresultadoquesepretendeessimplificarelprocesonecesario
para esa replicacin, facilitando por lo tanto eldesarrollodeservidorestolerantesa
fallos. Comoobjetivosecundario,perototalmentenecesarioparalaconsecucindel
anterior,Senseiextiendelosmecanismosdetransferenciadeestadodefinidosenel
Introduccin 3
modelo de sincrona virtual, esenciales para la consistencia entre servidores
replicados.
Para alcanzar estos objetivos, hemos considerado componentes individuales
(definidosporlasinterfacesqueimplementan)comolaunidaddereplicacin,loque
hasupuestodoslneasdeinvestigacin.
Porunlado,hemosanalizadolacreacindeesoscomponentes,loquesupone
no slo imponer un modelo orientado a objetos sobre una interfaz de menor nivel
basada en el paso de mensajes, sino tambin la necesidad de protocolos que
garanticen la consistencia de esos componentes, ya que son instanciados sobre
diferentes rplicas. La abstraccin as conseguida es la de un nico componente
compartidoporesasrplicas.
Por otro lado, hemos considerado la integracin de esos componentes para
construir aplicaciones tolerantes a fallos. Un problema asociado a esta integracin
eselciclodevidaespecialdeuncomponentereplicado,quepretendemosequiparar
al de un componente normal para facilitar su empleo. Otro problema importante es
la concurrencia de acceso asociada a esaabstraccindecomponentescompartidos,
loqueimplicalanecesidaddesolucionesalosproblemasdeconcurrenciaderivados.
Elplanteamientoempleadopararealizarestastareashasido:
Diseo de protocolos de transferencia de estado, directamente especificados
sobre el modelo de sincrona virtual e implementables por lo tanto en los
sistemasdecomunicacionesengrupoyaexistentes.
Especificacin de una interfaz de transferencia de estado a alto nivel para los
protocolos desarrollados. En especial, esta interfaz se ha integrado con la
especificacindelservicioCORBAdetoleranciaafallos.
Trasladarelniveldelainterfazempleadaeneldiseodeaplicacionesreplicadas
desde un modelo basado en intercambio de mensajes a un modelo basado en
objetoseinteraccionesentreobjetos.
Desarrollo de un sistema propio de comunicaciones fiables en grupo, bajo el
modelo de sincronavirtual,consoportedelasarquitecturasCORBAyJavaRMI
paralaespecificacindeinterfacesysuimplementacin.
Captura de patrones de diseo comnmente empleados en aplicaciones
replicables, con el objetivo de definir un entorno de implementacin que los
soporte.
Desarrollo de una metodologa de diseo de aplicaciones tolerantes a fallos
basada en su descomposicin en componentes, facilitando su implementaciny
lareutilizacindesoftware.
Implementacin de un sistema de soporte de la metodologa desarrollada,
permitiendoeldiseodeaplicacionesbasadasencomponentesreplicados.
Introduccin 4
Definicin de herramientas para la generacin automtica de componentes
replicados a partir de su definicin de interfaz y una implementacin de esa
interfazsinsoportedereplicacin.
Esta memoria se ha organizado en doce captulos, incluyendo esta
introduccin,ycuatroapndices.
El captulo 2 trata los sistemas distribuidos, explicando conceptos como
sockets, arquitectura CORBA, o modelos de mensajera y cliente/servidor. Su nivel
es slo introductorio, siendo su lectura innecesaria en caso de poseer ya esos
conocimientosbsicos.
El captulo 3 es tambin introductorio, esta vez sobre sistemas distribuidos
fiables, enfocado en los conceptos fundamentales de fiabilidad y tolerancia a fallos.
Estudialosproblemasasociadosalascomunicacionesengrupo,ydetallalasbases
para obtener comunicaciones multipunto fiables. Expone a continuacin el modelo
desincronavirtual,sobreelquesehadesarrolladoestetrabajo,ylosproblemasde
observabilidadsobreaplicacionesreplicadas.
En el captulo 4 se describen los sistemas existentes soportando
comunicaciones fiables en grupo. Esta descripcin es detallada en los mecanismos
detransferenciadeestadoentremiembrosdelgrupoqueesossistemassoportan,al
ser estos mecanismos una parte importante de esta memoria. Se estudian dos
sistemas en mayor profundidad: el servicio de tolerancia a fallosdeCORBA,porsu
importanciaactual,yEnsemble,desarrolladoporelcreadordelmodelodesincrona
virtualybaseinicialdeesteproyecto.
El captulo 5 es el primero de tres dedicado al estudio de la transferencia de
estado.Trata,desdeunaperspectivaformal,delosproblemasdelatransferenciade
estadoentremiembrosdeungrupobajoelmodelodesincronavirtual.Estudialas
condiciones que debe verificar una aplicacin replicada para poder emplear un
determinado tipo de transferencia, poniendo especial inters en el caso de
transferencias en varios pasos. Finalmente, propone algoritmos genricos que
solucionanlosproblemasexpuestos.
En el captulo 6 se desarrollan los protocolos de bajo nivel necesarios para
soportar transferencias de estado flexibles y eficientes. Se estudian diferentes tipos
de protocolos y se realizan comparativas entre esos tipos que permitan elegir el
protocoloadecuadoaunadeterminadaaplicacinoconfiguracintopolgica.
En el captulo 7 se estudia de nuevo el soporte de transferencias de estado
flexiblesyeficientes,peroahoradesdeelpuntodevistadelainterfazdeaplicacin.
Esta interfaz contempla problemas tales como la concurrencia de transferencias, la
eleccin del miembro que las coordina o el bloqueo de la aplicacin durante las
transferencias. Tambin se estudia la implementacin de las interfaces propuestas
sobrelosprotocolosdebajoniveldesarrolladosenelcaptulo6.
Enelcaptulo8sedescribeSenseiGMS,unsistemadecomunicacionesfiables
desarrolladoespecficamenteparaesteproyecto,quesoporta,medianteunainterfaz
Introduccin 5
CORBA o JavaRMI, el desarrollo de aplicaciones replicadas sobre el modelo de
sincrona virtual. Describimos esta interfaz, que define una funcionalidad
estrictamente limitada al modelo de sincrona virtual, y los algoritmos con que se
implementan, comparndolos con otros algoritmos existentes. Explicamos a
continuacin cmo emplear y configurar SenseiGMS e introducimos finalmente
VirtualNet,unsistemadesarrolladoparaprobaraplicacionesreplicadas,enfocadoen
losproblemasdecomunicacionesentrerplicas.
El captulo 9 parte del modelo orientado a objetos soportado por SenseiGMS
para desarrollar una metodologa de desarrollo de aplicaciones tolerantes a fallos.
Esta metodologa cubre patrones de diseo, como la sincronizacin requerida entre
solicitud y respuesta en los accesos a servidores replicados, o la transformacin de
operaciones sobre estos servidores en mensajes al grupo, y estudia la
automatizacin del proceso de replicacin ysuslimitaciones,enfocndoseentonces
en el empleo de componentes. La metodologa estudia la integracin de estos
componentes y los problemas de concurrencia que aparecen, incorporando
soluciones como monitores o transacciones. Por ltimo, comparamos el modelo
desarrolladoconeldelservicioCORBAdetoleranciaafallos.
El captulo 10 describe SenseiDomains, una implementacin de la anterior
metodologa desarrollada sobre SenseiGMS. Describimos su interfaz y soporte, y se
discutenlosaspectosydecisionesdeimplementacinqueafectanalametodologa.
En el captulo 11 se describe una aplicacin integral de Sensei, denominada
SenseiGMNS y que completa la implementacin del modelo de sincrona virtual. Su
diseo se realiza sobre SenseiDomains, con lo que sirve adems para mostrar un
ejemplodeaplicacindelametodologadesarrollada.
Finalmente,elcaptulo12muestralasconclusionesdenuestroproyectoysus
actualeslneasdeinvestigacin.
Esta memoria se completa con cuatro apndices. Tres listan las interfaces de
alto nivel de las diferentes partes del proyecto: SenseiGMS, SenseiDomains,
SenseiGMNS,yelltimomuestraejemplosdecomponentesreplicados.
Introduccin 6
Sistemasdistribuidos 7
Captulo2-SISTEMASDISTRIBUIDOS
Eltemadesistemasdistribuidosabarcaunamplioconjuntodeconceptoscuya
explicacin difcilmente puede reducirse a un captulo introductorio. Nos limitamos
aquaexponerunaseriedetrminosyconceptosqueempleamosalolargodeesta
memoria,detallandoigualmenteotrosporsuposibleasociacinconlosexpuestos.
La forma ms elemental de interpretar un sistema distribuido es la de un
sistema computacional compuesto por diferentes procesadores interconectados.
Normalmente, esta interconexin estar soportada por una red abierta, basada en
un conjunto deprotocolosestndarquepermita[Schmidt95a]lacolaboracinentre
aplicaciones,escalabilidadyportabilidad.
Esta interpretacin no es, sin embargo, completa; los componentes de una
aplicacin distribuida pueden residir en la misma mquina o en distintos nodosde
la red y, por lo tanto, al hablar de las interconexiones no se trata tanto de que se
produzcanatravsdeenlaceshardware,sinodecomunicacionesentreprocesos.
Lassiguientesseccionesmuestranlosconceptosenlosquenoscentramosen
esta introduccin: modelos distribuidos, sockets, procedimientos remotos, objetos
distribuidosytendenciasactuales.
2.1.Modelosdistribuidos
En todo servicio pueden identificarse dos papeles: el servidor, que procesa
una solicitud de servicio, y el cliente, que la enva. Laarquitecturacliente/servidor
[Berson96]esunmodelodistribuidodondeestospapelesseencuentranclaramente
diferenciados.UnejemploesunnavegadordeInternet:elnavegadoreselclienteque
accedeaunapginaWeb,suministradaporunservidorhttp.
En general, el trmino cliente/servidor se asocia a arquitecturas
centralizadas, donde una determinada mquina presta un servicio especfico. Sin
embargo, un servidor puede actuar a la vez como cliente de otro servidor. En
especial, dos componentes cualesquiera de una determinada aplicacin pueden
actuarsimultneamentecomoclienteyservidor,mutuamenteentres.Enestecaso,
tenemosunaaplicacinP2P(parapar)[Oram01],cuyaprincipalcaractersticaessu
descentralizacin. Un ejemplo muy conocido es Napster, un sistema de intercambio
deficheros
1
dondestosnoresidenenunservidorcentral,sinoencadaunadelas
mquinas conectadas al servicio. En este caso concreto, existe todava un servidor
central que mantiene las listas de ficheros, pero la carga de trabajo sobre este
servidoresmuchomenorquesituvieraquealbergarysuministraresosficheros.
Otraalternativaeselmodelodemensajeraoeventos,unmodelodistribuido
donde, aunque existen servidores y clientes, stos no se encuentran directamente
acoplados, es decir, el cliente no accede directamente al servidor para obtener la
informacin. En su lugar, se emplean entidades intermedias, generalmente
denominadas canales o colas de mensajes o eventos [Schmidt97]. En este caso, el
servidor enva su informacin en un mensaje, que se mantiene en una cola donde
puede ser accedido por el cliente o clientes. Este desacoplamiento entre servidor y
cliente implica que un determinado canal de informacin puede ser accedido por
mltiples clientes, pero tambin puede ser suplido por mltiples servidores. Y
resulta especialmente til para aplicaciones cuyos componentes no estn
permanentemente conectados. Este paradigma se emplea en el caso de correo
electrnico, donde entre el emisor y el receptor de un correo existe una cola de
mensajes.
En este ltimo caso la arquitectura sigue siendo cliente/servidor.
Simplemente se introduce una nueva entidad, la cola de mensajes o canal de
eventos, que acta como cliente para losproductoresdeeventosydeservidorpara
losconsumidores.
Existen otros modelos distribuidos, menos empleados o de dominio ms
restringido. Por ejemplo, JavaSpaces [Freeman99] define una estructura de datos
1
Los ficheros contienen msica codificada en formato MP3; el intercambio indiscriminado de
esta msicanorespetabalosderechosdeautorprovocdemandasjudicialesyelcierredelservicio,por
loquenonosesposibleindicarenestemomentounareferenciaasupginaWeb.
accesibleporlasdistintasaplicacionesdistribuidasquenoesmasqueunacoleccin
dedatosconpropiedadestransaccionables.AunquesedesarrollasobreJavaRMI(un
sistema que explicamos a continuacin), la abstraccin que ve el desarrollador es
simplementeundiccionario(HashMap)dondepuedeescribiroleerdatos,datosque
son entonces disponibles por las dems aplicaciones, sin necesidad de acceder al
modelodemensajesdeJavaRMI.Esteparadigmadeprogramacindistribuidanoes
original de JavaSpaces, est fuertemente influenciado por los sistemas Linda
[Gelernter85].
Otro ejemplo lo ofrece JavaParty [Philippsen97]. En este caso, la mquina
virtual de Java se implementa de forma distribuida, de tal forma que los objetos
declarados remotos pueden migrar sobre las distintas mquinas que integran el
entorno distribuido, para lo que hace falta modificaryextenderlasemnticadelas
operaciones. Aspectos inherentes a JavaRMI como el registro y publicacin de las
identidadesdelosobjetosremotosquedanocultosaldesarrollador.
2.2.Sockets
La comunicacin entre clientes y servidores, bajo cualquiera de los modelos
distribuidos, se realiza a bajo nivel sobre un determinado protocolo de red, siendo
TCP/IP el ms empleado. Cada dispositivo en red recibe una direccin IP nica (al
menosenelmbitodeesared)quelaidentificaparasuscomunicaciones.Unpunto
final de comunicaciones queda definido por la direccin IP y un nmero depuerto,
es decir, un mismo dispositivo puede tener mltiples lneas de comunicacin
abiertas,almenosunaporcadapuertoempleado.
La popularidad actual de TCP/IP se debe a Internet, que lo emplea como
protocolodered,yhasidoelprotocoloempleadoenmquinasUnixdesdesuinicio.
A principios de los 80 la distribucin Unix de Berkeley introdujo el modelo de
sockets como un mecanismo de comunicacin entre procesos [Leffler89], que se ha
convertido en el estndar de facto para programacin en red sobre TCP/IP. Sin
embargo, su API (interfaz de programacin de aplicaciones) puede en principio
usarseconotrosprotocolosdered.
Un socket [Stevens90] es un punto final de comunicacin, identificado en
TCP/IP mediante la direccin IP y un puerto. Existen dos tipos de sockets:
orientados a conexin (TCP) y sin conexin, tambin llamados datagramas (UDP).
TCPcreauncircuitovirtualentrelosprocesosquecomunica,porloquelossockets
sobre TCP se consideran fiables. Los datagramas no son fiables ni se asegura el
orden o no duplicacin de los datos enviados, pero permiten el envo de mensajes
broadcast,amsdeundestinofinal.
Unservidorqueempleasockets debeasociarseaunadeterminadadireccin,
dondeesperacontinuamentelallegadadedatos.Unclientedebeconocerculesesa
direccin especfica para enviarle datos. La informacin que se transmite no tiene
ningnsignificadoparalossockets,queactannicamentecomopuntosdeentrada
ysalidaparalascomunicaciones.Eslaaplicacinlaquedebeinterpretaresosdatos
yproducir,posiblemente,unarespuesta.
2.3.RPCLlamadasaprocedimientosremotos
Un ejemplo sencillo de aplicacin cliente/servidor es el de un servicio de
autentificacin:unclientesuministraunnombre(login)yunaclave(password),yel
servicio comprueba su validez. Empleando sockets, el cliente debe conectarse al
servidor y enviar en una cadena de bytes la informacin necesaria, el nombre y la
clave, que suponemos que son cadenas de caracteres. No existe ningn requisito
sobrecmoenviaresainformacinyelservidordebeespecificarquformatoespera.
Porejemplo,unprimerbytequeindiquelalongituddelnombre,seguidoportantos
bytescomocaracterestengaelnombre,yluegootrobytequeindiquelalongitudde
la clave y tantos bytes como caracteres tenga esa clave. Es responsabilidad del
cliente el aplicar correctamente el formato esperado. Y este formato debe
especificarse con mayor detalle: qu orden de bytes se espera, big-endian o little-
endian, qu codificacin de caracteres, ASCII o EBCDIC, etc. Adems, la aplicacin
debe gestionar los errores de comunicaciones. Desde el punto de vista del servidor
[Schmidt95b], si precisa soportar varios clientes simultneamente, es tambin la
aplicacin la que debe incluir toda la lgica de concurrencia y de gestin de
mltiplesclientes.
Unalibrerapuedesoportarelformateo/deformateodedeterminadostiposde
datos, definiendo cmo transferir cadenas de caracteres, tiposenteros,etc.Sitanto
el servidor como el cliente emplean la misma librera, parte de los anteriores
problemassesolucionan.RPC[White75]suministraestesoportedelibrera,alavez
que realiza una abstraccin de llamadas a procedimientos [Birrel84]. Siguiendo el
ejemplo anterior, el servidor puede especificarse como una funcin definida de la
siguientemanera:
intvalidate(inchar*login,inchar*password);
Al emplear un compilador RPC sobre esta definicin, se generan dos
porcionesdecdigo.Unasellamastubdelcliente,yloquehaceesproporcionarun
procedimiento con la misma definicin dada. El cliente invoca este procedimiento
[figura2.1],ysteautomticamentepreparalacadenadebytesaenviaralservidor,
formateando los datos y envindolos a travs del socket. La segunda porcin de
cdigo se denomina stub del servidor, y verifica continuamente el socket donde
recibe la informacin, que deformatea y enva al servidor. Cuando se elabora la
respuesta,staseenvaporelcaminoinverso.
De esta forma, se accede al servidor como si fuera local, al que le invoca
medianteprocedimientos,talcomosifueraunalibreradelsistema.
2.4.Objetosdistribuidos
La evolucin de los lenguajes de programacin hacia el paradigma de
orientacin a objetos supone que el procedimiento ya no eslaestructurabsicade
un programa, que pasa a estructurarse en objetos. Como extensin, los sistemas
RPCevolucionanpararealizarlaabstraccindeobjetosremotos.
JavaRMI (Remote Method Invocation) [Dwoning98] soporta esta abstraccin
sobreobjetosJava.Unobjetodistribuidoesaccesibledeformaremotaatravsdesu
interfaz,definidaenJava.ElcompiladorRMIgeneraapartirdeestainterfaz,aligual
queenRPC,porcionesdecdigoquesimulanelaccesolocaldelosobjetosremotos.
En este caso, el cliente emplea stubs o proxies, y al servidor se le asocian los
skeletons.
Ademsderealizarunaabstraccindeobjetosremotos,JavaRMIproporciona
otras facilidades a la aplicacin. Por ejemplo, dispone de un servicio de directorio,
denominado registro, donde las aplicaciones pueden publicar sus servidores,
asocindolos a un nombre. Un cliente no necesita ahora conocer la localizacin
exactadelservidor,bastaconqueaccedaaesteservicioparaobtenerunareferencia
al objeto remoto. Otra facilidad es el concepto de objetoremotopersistente,queno
est activo continuamente y se activa cuando un clienteloinvoca,loquefacilitael
escaladodelasaplicaciones.
RPC
Stubcliente
Cliente
RPC
Stubservidor
Servidor
Mensajes
dered
Flujo
aparente
Figura2.1.Filosofa deRPC
Aunque hemos descrito primero por su mayor simplicidad JavaRMI, CORBA
(Common Object Request Broker Architecture) [OMG98] es una arquitectura anterior,
diseada por el OMG (Object Management Group) con el mismo objetivo bsico:
manejarobjetosdistribuidosdeformatransparente.
En JavaRMI, todo el sistema se programa con un nico lenguaje, mientras
que CORBA soporta actualmente (como estndar) nueve: C, C++, Java, Cobol,
Smalltalk, Ada, Lisp, Python y CORBAScript. Por esta razn, la definicin de la
interfaz de los objetos remotos o componentes se hace en un lenguaje propio,
OMG/IDL.UncompiladordeIDL,especficoparacadalenguaje,generadenuevolos
stubsyskeletons.
La mayor complejidad no se debe slo a la variedad de lenguajes soportado,
sino a la funcionalidad que implementa [Orfali97]. Parte de esta funcionalidad se
incluye en el ORB, que es el gestor de objetos distribuidos, pero la arquitectura
[figura 2.2] emplea elementos opcionales, como los servicios CORBA [OMG97], que
implementan funcionalidad genrica, o las facilidades CORBA, que implementan
funcionalidad asociada a determinados tipos de aplicaciones. La figura 2.3 muestra
lasinteraccionesenelclienteyelservidor;suscomunicacionesserealizanatravs
del ORB y generalmente empleando los stub y skeleton generados. Sin embargo,
existen otras opciones; por ejemplo, el cliente puede desconocer en tiempo de
compilacinculeslainterfazdelservidoralqueaccede,encuyocasodebeemplear
lainterfazdeinvocacindinmica.
Unelementoimportanteenestaarquitecturaeseladaptadordeobjetos,cuya
finalidad es aislar al ORB del lenguaje empleado para implementar los servidores.
ORB
Servicios de objetos
Intf. aplicacin Intf. dominio Facilididades
comunes
Figura 2.2.Modelo de arquitectura OMA
Existen diferentes adaptadores, y el ms habitual es el POA (Portable Object
Adapter), que maximiza la portabilidad de las aplicaciones, a nivel de cdigo, sobre
diferentesimplementacionesdeORB.
Empleando la notacin de CORBA, se distingue entre servant, que es la
implementacin en un lenguaje especfico de la interfaz que define un servicio, y
servidor propiamente dicho, que eselobjetoactivocapazdeprocesarlaspeticiones
de servicio. Normalmente, existe un servant por cada servidor, pero una aplicacin
puede tomar otras alternativas, como que un servant encarne mltiples servidores.
Los servidores pueden ser persistentes, en cuyo caso el ORB los debe activar si
llegan peticiones de servicio, ylaaplicacinpuedeinclusoemplearunservantpara
cada peticin a un mismo servidor. Otra utilidad de esta distincin es que un
servidor puede migrar a una mquina diferente (donde emplea evidentemente un
servantdiferente)deformatotalmentetransparenteparaelcliente.
UnadelasprincipalesventajasdeCORBAessuinteroperabilidad,quepermite
que objetos implementados en lenguajes, sistemas operativos y tipos de mquina
diferente se comuniquen entre s. No es preciso quelosobjetosempleenunmismo
ORB, contalquelosempleadosseancompatiblesconlamismaversindeCORBA.
Es incluso posible que un objeto CORBA se comunique con un objeto JavaRMI, a
partir de la especificacin [OMG99] de RMI sobre IIOP, el protocolo estndar para
comunicacinentreORBssobreredesTCP/IP.
Existen otros gestores de objetos remotos. Por ejemplo, el sistema operativo
Windowsempleaunopropio,conunmodelodeobjetosdistribuidosllamadoDCOM
(DistributedComponentObjectModel)[Sessions97].Permitetambinlainteraccinde
Figura 2.3.InterfacesORB
Cliente Implementacin del objeto
Skeleton
IDL
esttico
Skeleton
dinmico
Adaptador
de
objetos
Invocacin
dinmica
Stubs
IDL
Interface
ORB
Ncleo delORB(ORBcore)
Haystubsyskeletons paracadatipo de objeto
Puedehabermltiplesadaptadores de objetos
Interfazidnticoindependientemente delORB
Interfazdependiente delORB
componentes escritos en distintos lenguajes, pero siempre sobre el mismo tipo de
mquinaysistemaoperativo.Noesposiblerealizaraesteniveldeintroduccinuna
comparativa entrelosgestoresexpuestos;as,aunqueanivelarquitectural,CORBA
est ms maduro, existen otras consideraciones que pueden inclinar la eleccin de
un gestor de objetos hacia DCOM o JavaRMI [Chung98, Gopalan98, Curtis97,
Juric00].
2.5.Tendenciasactuales
Empleando sockets, un servidor espera las solicitudes de servicio en una
direccin IP determinada y un puerto especfico. Ese servidor puede desarrollarse
empleandoJavaRMIoCORBA,peroaunasestdisponibleenunpuertoespecfico.
La tendencia actual a ofrecer servicios a travs de Internet implica que las
compaas instalan mquinas que son accesibles pblicamente, lo que supone la
posibilidaddeataquesmaliciososdondeunhackerescapazdeaccederalamquina
ensutotalidadyleerinformacinprivada.Unarespuestaaesteproblemaesocultar
las mquinas tras firewalls, que controlan el flujo de datos entrante y saliente; la
seguridad que se obtiene es mayor cuanto menos puntos de acceso tenga una
mquina, ya que cada puerto abierto (esto es, donde un servidor espera solicitudes
deservicio)esunpuntodbildelsistema.
Unsistemasegurodejaelmnimonmerodepuertosabiertos,ysloaquellos
cuyoprotocoloseconsidereseguro.Porejemplo,unservidorWebdebeseraccesible
deformaestndarenelpuerto80.Unaimplicacindirectaesladificultaddeofrecer
serviciospblicosmedianteservidoresCORBAoJavaRMIqueesperendirectamente
las solicitudes de servicio. Una alternativa factible recibe el nombre de http
tunneling.Significaquelassolicitudesserecibenatravsdelpuerto80(http),como
si fueran accesos Web normales; una vez recibidas, deben propagarse al servidor
especfico, resultando en su conjunto en una prdida de rendimiento y
funcionalidad.
J2EE, Java Enterprise [Allaramaju01], ofrece un amplio abanico de
posibilidadesenestesentido.Porejemplo,conJSP(JavaServerPages),seaccedea
una pgina Web cuyo contenido es dinmico, dependiente del estado del servidor;
puede recibir solicitudes de servicio que se propagan automticamente a unos
componentesJavadenominadosEnterpriseJavaBeansqueprocesanelservicio.Las
comunicaciones entre estos componentes se realizan mediante JavaRMI (la ltima
especificacinempleaRMIsobreIIOP).
El contenido de una pgina Web ha sido normalmente HTML, un lenguaje
basadoenetiquetasquepermiteespecificarelformatodelosdatosenelnavegador.
Un lenguaje similar es XML [W3C00], en cuanto a que est tambin basado en
etiquetas,peronotieneunaestructurafija.Esposibledefinirestaestructura,loque
lo hace muy conveniente para el envo de datos. Como stos se transfieren en
formato texto ASCII, pueden compartirse los datos con independencia de la
plataforma software y hardware. Es decir, dos componentes pueden enviarse
informacin en formato XML sin preocuparse por lenguajes de programacin o el
soporte hardware. Al definir su descripcin XML, definen las estructuras de los
datos que se intercambian, que pueden perfectamente identificar solicitudes de
servicio.
XML no define protocolos o mecanismos para la transmisin de los datos.
SOAP [W3C01] es un protocolo ligero basado en XML que permite la invocacin de
serviciosremotossobrehttp,yeslabasedelosserviciosWebqueestnempezando
a popularizarse. Al definirse sobre http, se pueden emplear todos los mecanismos
actualesempleadosparaelmanejodepginasWeb.
Todas las formas de comunicaciones mostradas estn basadas a nivel de
transporte en el empleo de sockets, pero el modo de acceder al servidor y a sus
servicios se realiza ahora a un nivel muy superior, definiendo de alguna forma la
interfazdeeseservidor.Conprocedimientosyobjetosremotos,lainterfazseenfoca
en la forma de acceder al servidor, definindose las operaciones a realizar para
invocarsusservicios,mientrasqueconXML,lainterfazseenfocaenlainformacin
aobtenerdeeseservidor.
2.6.Conclusiones
La eleccin de la arquitectura CORBA como marco de trabajo para la
realizacin de esta tesis se debe esencialmente a que en este momento ofrece el
modelo de programacin distribuida ms estndar, de amplia difusin en la
industria, y que soporta el paradigma de orientacin a objetos integrado en las
prcticas de ingeniera de software actuales. Asimismo, los resultados obtenidosen
estemodelosonfcilmentetrasladablesaotrastecnologassimilares.Pruebadeello
esquetambinsehanaplicadoenJavaRMIconmnimoscambios(reutilizandogran
partedelcdigodelossistemasimplementados).
Sistemasdistribuidosfiables 17
Captulo3-SISTEMASDISTRIBUIDOS
FIABLES
Este captulo realiza primero una introduccin a los sistemas fiables y a
continuacin,secentraenlosgruposdinmicosderplicascomomtodoparahacer
fiableunsistema.Losgruposdinmicossebasanenelmodelodesincronavirtual,
queempleacomunicacionesmultipuntofiables,yenunservicioquemanejalalista
dinmica de miembros del grupo. Este servicio y el modelodesincronavirtualson
descritos en detalle, as como la observabilidad del sistema: cmo es observado el
grupodecomponentesalactuarcomounnicoservidor.
3.1.Fiabilidad
Esta seccin introduce los principales conceptos asociados a sistemas fiables:
toleranciaafallos,fiabilidadydescripcindeesosfallos.Acontinuacindescribelos
sistemas distribuidos y los problemas adicionales que plantean respecto a
aplicaciones monoprocesador, as como la forma de detectar y simplificar esos
problemasaadidos.Finalmente,sedescribenlostiposdegruposdecomponentesy
lasbasesparaobtenercomunicacionesfiablesentrecomponentesdistribuidos.
3.1.1.Toleranciaafallos
Todoserviciopuededefinirseapartirdelconjuntodesalidasqueseproducen
apartirdeunasentradas,definicinquedebecomplementarseconlasemnticade
fallos del servicio, que especificaloserroresposibles.Existenvariasclasificaciones
deestoserrores[Christian91,Birman96]
Falloporomisin:elservicionorespondeaunaentradaomensaje.Puedesera
suvezunfalloenlaemisindelmensajeoensurecepcin.
Fallo de temporizacin: la respuesta llega fuera de un margen de tiempo
especificado(mrgenesmnimoymximo).Estefallopuededarseporproblemas
ajenosaloscomponentesmismoscomo,porejemplo,fallosenlared.
Fallo en la respuesta: el servicio ofreceunarespuestaincorrecta.Enestegrupo
deerroresentranlosfallosbizantinos[Lamport82].
Fallo por cada: el servicio se cae. Este error viene acompaado evidentemente
porunodelosanteriores.
Estos fallos pueden ocurrir tanto en componentes hardware como en
componentes software. En este ltimo caso, los errores que provocan los fallos se
clasificanenlasdoscategorassiguientes:
Bohrbugs:fcilmentereproducibles,resultafcilencontrarlosyfijarlos.
Figura 3.1.Soporte de errores enla respuestausandoreplicacin
getCounter
getCounter
getCounter
Return 5
Return 4
Return 5
getCounter
Return 5
Heisenbugs: difciles de reproducir, resulta complicado encontrarlos y,
consecuentemente,fijarlos.
La tolerancia a fallos de un sistemaessuhabilidadpararecuperarsetrasel
fallo de algn componente. Otros dos conceptos relacionados son la fiabilidad y la
disponibilidad del sistema: la fiabilidad de un servicio da la probabilidad de
comportamiento correcto de ese servicio, y su disponibilidad es el porcentaje de
tiempoenqueelserviciopuedeproporcionarse.
Una forma de incrementar la tolerancia a fallos de un sistema es la
replicacindesuscomponentes[Neumann56].Siuncomponentesecae,elsistema
puede an emplear su rplica o rplicas. La forma en que estas rplicas deben
trabajar depende de la semntica de fallos de los componentes. Por ejemplo, si
pueden dar eventualmente respuestas errneas (fallo en la respuesta), el servicio
puedeaccederatodaslasrplicasydarlarespuestamayoritaria[figura3.1].
3.1.2.Sistemasdistribuidos
Una aplicacin puede tolerar fallos en la implementacin de un algoritmo
[Maguire93]empleandounaimplementacinalternativaindependiente,posiblemente
no optimizada, que pueda comprobar los resultados dados por el primer algoritmo.
Esdecir,seempleandistintasimplementacionesyposiblementedistintosalgoritmos
paraevitarerroresdecodificacinodelgicaenelalgoritmo.Siesaaplicacindebe
tolerar fallos en el ordenador sobre el que se ejecuta, deber procesarse en dos o
ms ordenadores y sincronizar de alguna manera las distintas instancias de esa
aplicacin, lo que lleva al concepto de computacin distribuida. Este concepto
implica un conjunto de programas fuertemente acoplados, ejecutndose en dos o
msordenadoresycoordinandosusacciones.
Para conseguir que una determinada arquitectura tolere fallos en sus
componentes, debe ser capaz de detectar cundo esos componentes fallan, y esta
deteccinestrelacionadaconelmodelodistribuido:
Sistemas sncronos: fuertemente dependientes de la temporizacin, todos sus
componentes comparten una medida de tiempo; esta sincronizacin de los
componentes permite dividir el tiempo en periodos (que todos los componentes
ven iguales), siendo los mensajes enviados al principio de cada periodo y
procesados al inicio del siguiente. Asume, por consiguiente, una perfecta
coordinacin de los componentes y sus acciones, coordinacin quenoexisteen
la inmensa mayora de los sistemas reales. Detectar lacadadeuncomponente
esinmediato.
Sistemas asncronos: el concepto del tiempo desaparece, lo que impide realizar
suposicionessobrevelocidadesdelared,delosprocesos,etc.Nohaylmitesen
los retrasos de los mensajes o en el tiempo necesario para ejecutar cualquier
pasoyesimposibledetectarsiuncomponentesehacadooessimplementemuy
lento. Es un modelo irreal, que permite realizar simples abstracciones del
sistemaaleliminarelconceptodetiempo.
Sistemas intermedios, denominados asncronos reales o asncronos parciales:
existe el concepto de tiempo, y los mensajes entre componentes se realizan
dentro de unos lmites de tiempo. Esta definicin es muy amplia, pues esos
lmitesnotienenporquserconocidosoestables;segnsedefinan,seobtienen
distintossistemasasncronosparciales[Dwork88].
La deteccin de fallosest,consecuentemente,ligadaalasincronizacindel
sistema, y cuanto ms sincronizado sea ste, ms factible ser realizar una
deteccin de fallos fiable. En un sistema real, cuando un componente enva un
mensajeaotro,esperaunarespuestaenuntiempomximo.Vencidoestetiempo,el
componente debe suponer un fallo, pero no puede decidir dnde se ha producido
ste,pueselproblemapuededebersea:
Problemas en las comunicaciones: el mensaje no ha llegado alotrocomponente
que, por lo tanto, no lo ha procesado, o bien hallegadoylohaprocesado,pero
noseharecibidolarespuesta.
Elcomponentesehacado.
Elcomponenteesmuylento,oestprocesandomuylentamenteelmensajepor
otrascausas.
Enestascondiciones,elprimercomponentenopuedesabersielsegundose
hacadoonoy,enesteltimocaso,sihaprocesadoelmensajeono;porestarazn,
los algoritmos para las comunicaciones entre estos componentes resultan muy
complicados.
Una forma de simplificar los algoritmos en aplicaciones distribuidas es
disponerdeunsistemaquegestioneestosproblemasylibereaesosalgoritmosdela
lgicaasociada;esesistemasonlosdetectoresdefallos.
3.1.3.Deteccindefallos
Un detector de fallos comprueba que los componentes de un sistema no
presentan errores, y si detectan un fallo, lo comunican a los dems componentes.
Pero, al igual que un componente no puede determinar si otro ha fallado o no, el
detectordefallostampocopuedeconsiderarseseguroyelsistemadebesoportaruna
deteccinincorrectadefallosdeloscomponentes,paraloquehaydosopciones:
La aplicacin considera que el detector de fallosesperfecto;cualquierelemento
que el detector de fallos considera sospechoso lo es para siempre, siendo
excluidodelgrupo.
La aplicacin considera que el detector de fallos es imperfecto; sus algoritmos
deben entonces ser capaces de progresar sabiendo que estas detecciones son
imperfectas,ynoconsiderarexcluidosaloscomponentessospechosos.Lalgica
delgruporesultamuchomscomplicadaqueenelprimercaso.
Laimplementacindeundetectordefallosserealizageneralmentemediante
temporizadores. Cada componente emite mensajes, cuya recepcin permite a los
demscomponentescomprobarquenosehacado.Silaaplicacinconsideraqueel
detector es perfecto, estos temporizadores deben ser lo suficientemente largos para
que el nmero de fallosseamnimo,puestoquesusfallosexcluyendirectamentea
losmiembrossospechosos.Existenotrosmtodosparadetectarlosfallos,basndose
en caractersticas determinadas de un sistema o arquitectura, pero no pueden
considerarsegenricas.
Undetectordefallospermitecomprobarsiundeterminadocomponenteseha
cadoono.Yunfalloenlascomunicacionesconuncomponentepuedeversecomo
unfallodeesecomponente.Elproblemasurgeenqueelotrocomponentenoseha
cado, pero observar recprocamente un fallo en el primer componente, con lo que
hay dos componentes que sospechan mutuamente uno del otro. Extendiendo este
razonamiento, un problema real en los enlacesconlosqueungrupoderplicasse
comunica puede provocar la creacin de dos o ms subgrupos, sospechando cada
unoquelosdemsestnfallando:laparticindelaredhaprovocadounaparticin
del grupo. Como adems el detector de fallos es imperfecto, un enlace lento puede
provocar el mismo resultado; en este caso, una particin virtual de la red puede
suponerunaparticindelgrupo.
3.1.4.Gruposdecomponentes
Una forma de incrementar la tolerancia a fallos de un sistema es la
replicacin de sus componentes: este grupo de componentes es visto como una
entidad nica, y un cliente que deba acceder al servicio prestado por ese
componente acceder al grupo como un ente, sin conocer el nmero, identidad o
localizacionesdelosmiembrosindividuales.
Estos grupos pueden ser estticos o dinmicos; los grupos estticos estn
formados por un conjunto predeterminado de elementos. Incluso cuando estos
elementossecaen,siguenperteneciendoalgrupo;porello,siunelementotomauna
decisin, todos los dems, incluidos los elementos cados, estn obligados a seguir
esa decisin. Se supone, por lo tanto, que el elemento cado puede volver a
levantarse, y debe haber guardado la informacin necesaria para completar esa
decisin.
En los grupos dinmicos, la lista de elementos del grupo se considera
dinmica, y la misma lgica del grupo contempla la inclusin y exclusin de
miembros. Un elemento cado queda directamente excluido del grupo. Si un
elementotomaunadecisin,slolosdemselementosquepermanezcanfuncionales
deberntomarlaigualmente.Haydostiposdegruposdinmicos:
Grupos dinmicos no uniformes: si un elemento toma una decisin pero se cae
antesdecomunicarlaalgrupo,noesprecisoqueloselementosactivosrestantes
tomen esa misma decisin. Adicionalmente, si toma una decisin y se la
comunica a una parte del grupo, pero tanto ese elemento como los que han
recibido la comunicacin se caen, los dems elementos activos no estn
obligados a tomar esa decisin. Por ejemplo, un cajero automtico, en la
extraccin de pequeas cantidades de dinero, no necesita comunicar esa
extraccin y luego procesarla. Si se cae, un registro contiene esa informacin,
conloquelatransaccinnosepierde.
Gruposdinmicosuniformes:inclusosielelementoquetomladecisinsecae,
los dems elementos activos deben tomar la misma decisin. En el ejemplo
anterior, para grandes cantidades de dinero, un cliente podra crear un gran
descubierto si accede a varios cajeros que entregan el dinero y, antes de
comunicarlatransaccin,elcajerocorrespondientesecae.
Estos distintos tipos suponen distintos grados de consistencia, siendo la
menor consistencia la alcanzada enlosgruposdinmicosnouniformes.Losgrupos
dinmicos son ms potentes y tolerantes a errores que los estticos, pero resultan
tambinmsdifcilesdeimplementar.
3.1.5.Comunicacionesfiables
Siunservicioseimplementamedianteungrupodecomponentesdistribuidos
para aumentar su tolerancia a fallos, esos componentes debern estar en
comunicacin para preservar la consistencia del sistema, y que cada componente
presenteunavisincoherentedeeseservicio.Esascomunicacionespuedenser:
Comunicaciones punto a punto: un componente se comunica con el resto
mediantemensajesindividualesacadaunodelosmiembrosdelgrupo.
Comunicaciones multipunto (multicast) no fiables, como IP multicast. Estas
comunicaciones pueden resultar apropiadas para aplicaciones no crticas en la
recepcindemensajes,dondelaprdidadeunmensajenoafectaalestadodela
aplicacin. Por ejemplo, aplicaciones multimedia, donde la prdida del mensaje
puede simplemente suponer la falta de actualizacin en uno o varios frames de
vdeo.
Comunicacionesmultipuntoatmicas:segarantizaqueotodosoningunodelos
componentesprocesanlacomunicacin.Puedeserdinmicamenteuniformeono
[Malki94]; si es uniforme, cuando un proceso procesa un mensaje, todos los
demsprocesosenestadooperacionallodebenprocesar
Comunicaciones multipunto best-effort, que no se consideran atmicos (todos o
ninguno),puessuobjetivoescasitodosocasininguno;acambio,resultanmuy
escalables y ms apropiados, consecuentemente, para grandes grupos. Por
ejemplo, en el protocolo multicast bimodal [Birman98], los componentes se
comunicanperidicamenteconotrosparacomprobarsihanrecibidolosmismos
mensajes;siexistealgndesfase,setransmitenlosmensajesquefaltan.Trasun
periodo de tiempo determinado tras la recepcin de un mensaje, pueden
procesarlo asumiendo que si hubiera habido algn desfase, ya se habra
detectado; si la deteccin de un mensaje no recibido se realiza despus de
procesar algn mensaje posterior, la aplicacin debe ser capaz de retroceder al
punto inicial. Puesto que para detectar si faltan mensajes un componente se
comunicaaleatoriamenteconotros,peronocontodos,ladeteccinnoessegura,
yprecisadeunamayorcalidadenlascomunicaciones:noesaplicabledeforma
general.
Ademsdelascondicionesdeatomicidad,lascomunicacionessecaracterizan
por el orden de procesado, es decir, el orden con que distintos componentes van a
procesarlosmismosmensajes:
Procesarlosmensajessinorden,talcomollegan.
Ordenfifo:losmensajesenviadosporuncomponenteseejecutanenelordenen
quesonenviados.
Ordencausal:losmensajesenviadosporunoovarioscomponentes,quepuedan
relacionarse causalmente, se procesan de acuerdo a esta relacin. Por ejemplo
[figura 3.2], si un componente A enva un mensaje y un componente B, al
recibirlo,envaunsegundomensaje,elprimeroprecedecausalmentealsegundo,
ydondeambosmensajesdebanserprocesados,loharnenelordendebido.Es,
porlotanto,unordenfifoincluyendoavarioscomponentes.
Figura3.2.Orden causal
A B C
m1
m2
m1precede
causalmente am2
m2llegaantesquem1:orden causalnorespetado
A B C
m1
m2
Orden causal
m2
m1
m2
m1
Orden total: todos loscomponentesdelsistemaqueprocesenunconjuntoigual
demensajes,losprocesarnenelmismoorden.
Orden total causal: orden total preservando la causalidad. Si un componente
envadosmensajes,elordentotalnoimplicaqueelprimermensajeenviadodebe
ejecutarseantesqueelsegundo,sinoqueeseordendeprocesadoserconstante
en los dems miembros del grupo: es decir, si todos los miembros procesan
primero el ltimo mensaje y luego el primero, el orden total queda todava
preservado.Elordentotalcausaleliminaestaposibilidad.
Segn sea el tipo de orden asociado con el multicast, se producirn
determinadoserroresdeobservacindelosmensajesoeventos[Fidge96]:
Observadores diferentes viendo diferentes ordenaciones: dos eventos
concurrentespuedanservistosendistintoordenpordosprocesos.
Ordenaciones incorrectas: incluso cuando un mensaje precede causalmente a
otro,esteordennoesvistoenunprocesodado(generalmenteporretrasosenel
envodemensajes).
Indeterminismo en la observacin de los eventos: el mismo proceso en las
mismascondicionesgeneralesveloseventosendistintoordencuandoseejecuta
variasveces.
Ordenacionesarbitrarias:unprocesoquerecibeuneventoantesqueotrodeduce
queloprecedecausalmente(cuandopuedenserconcurrentes).
Las opciones de ordenacin se denominan dbiles o fuertes segn sean
dinmicamente uniformes o no (segn involucren o no a los componentes que
Figura 3.3.Gapfreedom
A B C
m1
m2
Orden causal:m1precedeam2 Fallo
enA
m2no puedeprocesarsehastahaberprocesado m1.
B deberecibirunacopia dem1(deC)
fallan). Por ltimo, hay una propiedad adicional relacionada con el orden de
mensajes, denominada gap freedom: si el orden exige que un mensaje m1 sea
procesado antes que m2, que m2 se procese implica que m1 tambin debe haberse
procesado.Lafigura3.3muestraelresultadodeaplicarestapropiedad;unmiembro
A enva antes de caerse un mensaje m1, que alcanza al miembro C pero no a B. El
miembro C enva antes de detectar la cada de A un mensaje m2 que,
consecuentemente, sucede causalmente a m1. Cuando B lo recibe, no puede
procesarlo; aplicando la propiedad de gap freedom, slo puede procesarlo tras m1,
por lo que C, o cualquier otro miembro del grupo que lo hubiera recibido, debe
enviarleprimerounacopiadeesemensaje.
3.2.Serviciodemiembrosdegrupo(GMS)
Los miembros de un grupo dinmico deben permitir la inclusin de nuevos
miembrosolaexclusindemiembrosactualesdelalista.Ademsdelosproblemas
naturales de consistencia del grupo, se aade el manejo de las posibles
inconsistencias que se pueden producir coneltratamientodelalistademiembros.
Por esta razn, los grupos dinmicos se apoyan en un servicio externo, el GMS
(GlobalMembershipService),querealizalagestindelalistademiembrosdelgrupo.
La interfaz bsica de este servicio permite la inclusin de los componentes
que soliciten incorporarse al grupo y la exclusin de miembros, bien porque lo
solicitenoporquesesospechequefallen.Paraello,debeapoyarseenundetectorde
fallosyhacerlasfuncionesdelmismodecaraalgrupo.Segnlalistademiembros
va cambiando, el GMS enva esta lista en forma de vistas a los componentes que
quedanenelgrupo.Elcontenidodelavistapodrserlalistacompletaolalistade
cambiosrespectoalaanteriorvista.
Mediante este servicio, el grupo slo debe encargarse de su propia
consistencia;comoademselGMSactacomodetectordefallos,secreaunentorno
dondelosnicosfallosquevenlosmiembrossonlosdecadadelosotrosmiembros.
LoserroresenlascomunicacionessonabsorbidosporelGMS,quelostransformaen
nuevas vistas; efectivamente, ante cualquier error o sospecha de error de un
componente, el GMS lo elimina del grupo, temporal o permanentemente, enviando
unanuevavistaalosdemscomponentes.Laformadeinstalarestasnuevasvistas
debe garantizar la propiedad denominada sincrona de vistas (view synchrony)
[Babaoglu96]: todos los componentes que sobreviven dos vistasconsecutivasdeben
haberprocesadoelmismojuegodemensajesenlaprimeravista.Estapropiedades
fundamental para mantener la consistencia del grupo entre las vistas; si un
miembronohaprocesadoalgunodelosmensajesquelosdemshanprocesado,no
sepodragarantizarsuconsistencia.
Los miembros de un grupo van recibiendo diferentes vistas del grupo segn
nuevos miembros se incluyen o quedan excluidos. Cuando un miembro intenta
comunicarse con otro y se produce unproblemaenesacomunicacin,transmiteel
error al GMS, que considerar que uno o los dos miembros falla, excluyndole
consecuentementedelalista.ElempleodelGMSpermitesimularunentornodonde
los nicos fallos son por cada del componente [Sabel94], ocultando todo problema
de comunicaciones y particionado de la red, en tanto ese GMS permanezca activo.
Puesto que este grupo pasaadependercompletamentedeesteservicio,unfalloen
ste provocar la parada del grupo. Por esta razn, el GMS mismo debe estar
replicado, es asimismo un grupo dinmico que se autogestiona mediante un
protocolo denominado GMP (Global Membership Protocol). Al igual que el GMS
permite incluir y excluir miembros de sus grupos, el GMP permite incluir y excluir
miembrosdelGMS.
Un particionado de la red provocar un particionado no slo en el grupo de
componentes de una aplicacin, sino tambin en el grupoqueimplementaelGMS.
En caso de una particin, ste reportar una nueva vista a los componentes en la
particin; pero paralelamente la otra particin o particiones del GMS podran
reportar vistas complementarias a los otros componentes, lo que supondra la
existencia de varios grupos aislados que consideran que los dems han cado. El
GMScontrolasupropialistademiembrosylaslistasdelosgruposasociados;sise
particiona, tiene las siguientes opciones respecto a su propia lista de miembros
[Ricciardi93]:
Norealizarningnprogreso.Loquesuponenopermitirquenuevosmiembrosse
incluyanenelGMSoalgunodelosmiembrosactualesloabandone.
Una particin se considera primaria y puede seguir haciendo progresos. Las
dems dejan de prestar servicio, debern incluirse de nuevo en el GMS. La
particin primaria puede determinarse de varias formas; por ejemplo, por
mayorademiembrosenelmomentodelaparticin.
Varias particiones pueden progresar, pudiendo dar vistas concurrentes a
diferentesmiembrosdelgrupo.SielGMSmismopuedeseguirhaciendoprogreso
encasodeparticin,losdistintossubGMSsquesecreanpodranevolucionarde
tal forma que, al recuperarse la particin, ninguno de los componentes de una
particin supiera de la existencia de los componentes de otra particin. En ese
caso no podran comunicarse, haciendo definitiva la particin, por lo que esta
situacindebe,claramente,evitarse.
Enunsistemanormaldesincronadevistas,elGMSpuedeirevolucionando
en caso de particin, pero slo en una particin. La forma de asegurar su
consistencia es precisando que una mayora de los componentes de una vista del
GMS aprueben la siguiente vista. sto significa que si un sistema dinmico, por
sucesivos fallos o particiones pierde ms de la mitad de sus miembros, podra
progresar siempre que cada fallo no implicara a la vezaunamayorademiembros.
Por ejemplo, si hay diez miembros, y una primera particin supone la cada de
cuatromiembrosyunasegundaparticinlacadadedosmiembros,elGMSpodra
en cada paso asegurar una mayora para progresar. Los miembros del grupo que
soporte, como consecuencia, siguen recibiendo vistas si se encuentran en la
particinprimaria;sino,dejanderecibirvistasydeprestarningunafuncionalidad.
La particin primaria no tiene porqu estar definida en funcin de una
mayora de componentes. Esa mayora puede estar balanceada de tal forma que
determinados componentes tengan un mayor peso que otro, con lo quelaparticin
primariayanoseralaquehaquedadoconunmayornmerodecomponentes,sino
conunmayorpesodestos.
Aunque una aplicacin que pueda funcionar en modo particionado presenta
unamayordisponibilidad,sudiseoestambinmscomplicado.Adems,mientras
quelasincronadevistasesunmodelomuyelegante,dondeelGMSgestionatodos
los cambios en las vistas, los sistemas llamados de sincrona de vistas extendida
(extended view synchrony) [Babaoglu96], soportando vistas concurrentes, no lo son
tanto y requieren la cooperacin de la aplicacin. Por otro lado, cuanto mayor
(geogrficamente) sea un sistema, ms frecuentes y prolongadas podrn ser las
particiones, lo que puede implicar la necesidad de soportar particiones en estos
sistemas.
3.3.Sincronavirtual
Apartirdelasprimitivasdecomunicacionesfiablesmultipuntoydelservicio
GMS, que hace a su vez uso de esas primitivas, es posible describir el modelo de
sincrona virtual [Birman87], usado en todos los sistemas distribuidos asncronos
actualesquesoportangruposdinmicosypropiedadesdeconsistencianotriviales.
Este modelo se basa en el siguiente principio: si todos los miembros
procesaran los mismos mensajes en el mismo orden (orden total), no habra
posibilidades de inconsistencia entre ellos. El modelo de sincrona virtual se basa
adems en la posibilidad de que, aunque dos miembros procesen dos mensajes en
distinto orden, el resultado puede ser an el mismo: de esta forma, al permitir
emplearprimitivasdecomunicacionesmenosestrictasenelorden,comoordenfifoo
causal,elrendimientoresultamayor.
Elserviciodemiembrosdegruporequeridoporestemodelodebecumplirlas
siguientespropiedades:
Soportedinmicodegrupos:exclusineinclusindemiembrosdinmicamente.
Envo de vistas a los miembros del grupo, donde todos ven la misma secuencia
devistas.
Sincrona de vistas: dos miembros que sobreviven a dos vistas consecutivas
procesan los mismos mensajes. Los sistemas que soportan sincrona extendida
devistasrelajanestapropiedad,puesmiembrosdevistasconcurrentesnoestn
obligadosahaberprocesadolosmismosmensajes.
Gap-freedom: si el grupo procesa un mensaje, que es sucesivo en el orden
establecido a otro mensaje dado, el grupo ha procesado tambin este ltimo
mensaje.
Adems, el modelo precisadeprimitivasdecomunicacionesmultipunto,con
uso preferente de orden fifo y causal en las comunicaciones. Los algoritmos de
comunicaciones del grupo [Birman96] pueden desarrollarse basndose en
comunicaciones totalmente ordenadas, reemplazando luegolascomunicacionescon
primitivas con menor orden, y pasando de entornos dinmicamente uniformesano
uniformes, mejorando notablemente el rendimiento ofrecido. Adems, al emplear
estas primitivas de comunicaciones que no emplean orden total, los distintos
miembros del grupo podrn procesar los mensajes en distinto orden, tolerando as
erroressoftware(Heisenbugs):sitodaslasrplicasprocesaranlosmismosmensajes
enelmismoorden,yhubieraunerrorsoftware,todaslasrplicasfallaranporigual.
Hay estudios que prueban que la mayora de los erroresenunsistemasonerrores
software [Chou97], luego tolerar estos errores resulta ser una consecuencia muy
interesantedelempleodeprimitivasdecomunicacionessinordentotal.
3.4.Observabilidaddelgrupo
Los puntos anteriores han estudiado los mtodos para mantener la
consistencia dentro del grupo, usando un servicio GMS y mediante unas
comunicaciones atmicas preservando el orden necesario. Sin embargo, hay otras
comunicacionesatenerencuenta,externasalgrupoyquenopuedendisearsede
la misma manera. Hay que considerartambineltipodereplicacindelsistema:si
todaslasrplicastienenlamismafuncionalidadono.
3.4.1.Comunicacionesexternasdelgrupo
Cuandouncomponenteindividualaccedealgrupo,tienevariasopciones:
Accederaunmiembrodelgrupo,quepropagalaaccinarealizar[figura3.4].Si
el miembro se cae o es expulsado del grupo, el resultado es indeterminado. El
miembro al que se accede puede elegirse de tal forma que la carga sobre cada
miembroestbalanceada.
Accederatodoslosmiembrosdelgrupo[figura3.5].Lacargadecomunicaciones
es mayor y el componente debe conocer la composicin exacta del grupo, aun
siendodinmica.Semultiplicanaqulasopciones,puespuederesponderunslo
miembro o todos o un nmero determinado de ellos. Si el cliente no conoce la
composicin exacta, pueden originarse problemas al no acceder a los
componentesadecuados.
Adems, deben contemplarse las opciones de orden de sus mensajes. En el
casodeuncomponentequeaccedesncronamenteaungrupo,cuandostedevuelve
la respuesta, no es necesario que todo el grupo sea an participe de la accin
realizada. Por consiguiente, si ese componente accede a otro miembro del grupo,
pueden crearse situaciones de inconsistencia al no respetarse el orden de los
mensajes.Unasolucinposibleesnodevolverelresultadoalcomponentehastaque
todoelgrupoconozcalaaccin.
Estascomunicacioneshaciaelgruponotienenporqupartirexclusivamente
de un componente individual, tambin pueden provenir de otro grupo, y debe
resolversesislounmiembrodelgrupoquesolicitaelservicioobientodoelgrupo
deberecibirlarespuesta.Delamismamanera,siuncomponenteindividualaccede
aungrupo,debedecidirsesirecibirunanicarespuesta(accesotransparente)ola
respuesta de todos los miembros. En este ltimo caso, pueden fijarse varias
variables,comoelnmeromnimoderespuestasarecibir,oelintervalomximode
esperadelasrespuestas.
Existen varias soluciones para el problema de orden de mensajes entre
diferentesgrupos:
Noestablecerningnordenenlosmensajesentregrupos,loquepuederesultar
perfectamenteadecuadosiestosgruposestnpocoacoplados.
Establecer un orden global en el sistema, de tal forma que todas las
comunicacionespreservensucausalidad.Ademsdeserunasolucinmuycara,
imponeuncostealascomunicacionesquenonecesitenpreservarningnorden.
Figura 3.4.Propagacin de acciones enel servidor
Update:X
Update:X
Update:X
Update:Y
Update:Y
Update:Y
Cada grupo controla la causalidad de los mensajes que enva y recibe; de esta
manera,noenviarningnmensajehastaquetodoelgrupoconozcaelmensaje
entrante que lo origin. No se respeta slo el orden de los mensajes salientes
respectoalosentrantes,sinotambindelosinternos;siunmensajeseproduce
como consecuencia de uno o ms mensajes internos, el mensaje slo saldr
cuandotodoelgrupoconozcatodossusmensajesprecedentescausalmente.Este
mtodosedenominaconservativo[Birman96]ypermiteconservarelordendelos
mensajesconcernientesaungrupo,peronopreservaelordenglobaldelsistema.
Una solucin similar a la anterior es el empleo de protocolos flush: completar
todas las comunicaciones internas del grupo antes de enviar un determinado
mensaje fuera del grupo. Es un caso concreto de la anterior solucin, donde se
desea que slo algunos mensajes respeten la causalidad, y en esos casos se
realizaunflushantesdeenviarelmensaje.
Cuando varios grupos estn fuertemente acoplados, otra solucin es crear un
supergrupo o dominio que los incluya, permitindose entonces emplear las
primitivasdecomunicacionesdeungrupo:ordenfifo,causal,etc.
3.4.2.Replicacin
Al definir los grupos de objetos, se ha presupuesto que todos estaban en el
mismo nivel. Sin embargo, la replicacin puede realizarse de varias maneras: todos
los miembros activos [Schneider93], un solo miembro activo y los dems en pasivo
Figura 3.5.Propagacin de accionespor el cliente
Update:X
Update:Y
Update:X
Update:X
Update:Y
Update:Y
[Budhiraja93], o el estado intermedio, donde varios miembros estn activos y los
demssonpasivos[figura3.6].
Esta replicacin activa/pasiva puede entenderse como dos grupos de las
mismasrplicasdondeungrupo,elactivo,procesatodaslaspeticionesdeservicioy
actualiza peridicamente al segundo grupo;uncomponentedelgrupopasivopuede
incluirseenelgrupoactivosiseproduceunfalloenste,abandonandoasuvezel
grupo pasivo. ste es en un proceso monitorizado externamente, mediante un
sistemaqueobservalosfallosenlosgruposymuevemiembrosdeungrupoalotro.
Relacionadoconelmodelodereplicacinestelconceptodebalanzadecarga,
que permite promediar la carga de servicio que cada componente del grupo debe
soportar. Este concepto se introdujo brevemente en el apartado anterior al discutir
los mtodos con que un cliente puede acceder al grupo. Si el grupo se diseapara
hacerbalanzadecarga,elclientepuedeelegirelmiembroalqueaccedeconfinado
entonces en un acceso promediado- o el acceso puede realizarse sobre todos los
elementosdelgrupo,decidiendosteculdebeprocesarelservicio.
Figura 3.6.Modelomixto de replicacin
Rplicasprimarias Rplicassecundarias
Las rplicasprimariasestncontinuamentesincronizadas.
Las secundarias se actualizanperidicamente
Sistemasdecomunicacionesengrupo 33
Captulo4-SISTEMASDE
COMUNICACIONESENGRUPO
Losanteriorescaptuloshanmostradolasopcionesdecomunicacionespuntoa
puntodisponiblesactualmenteylasformasdecomunicacionesengruponecesarias
para crear aplicaciones distribuidas fiables mediante la replicacin de sus
componentes.
Lossistemasdecomunicacionesengrupoexistentessebasanenelmodelode
sincrona virtual. Una de las propiedades que este modelo precisa [Birman96] es el
soporte de la transferencia de estado, pero lasaproximacionesempleadasparaeste
soportevaranenormementeentrelosdistintossistemas.Latransferenciadeestado
es uno de los objetivos cubiertos por Sensei, pero antes de presentar el modelo
desarrollado, es necesario mostrar los sistemas existentes y su modelo de
transferenciadeestado.
4.1.Sistemasdecomunicacionesengrupo
Sobre el modelo de sincrona virtual se han desarrollado varios sistemas de
comunicaciones de grupos.Acontinuacinsemuestraunalistaconlosprincipales
sistemas (restringidos a interfaces Java, C y C++) que soportan toleranciaafallosy
excluyendo sistemas comerciales de dominio restringido. Dos sistemas se han
postergadoalasseccionesfinales,entrandoenmayordetalleensuimplementacin,
por su influencia en la especificacin y el desarrollo de Sensei: Maestro (sobre
Ensemble)ylaespecificacindetoleranciaafallosdeCORBA.
4.1.1.Amoeba
Amoeba [Amoeba] es un sistema operativo basado en microkernel que
transforma un grupo de estaciones de trabajo en un sistema distribuido
transparente [Tanembaum91]. La idea bsica es presentar al usuario la ilusin de
un nico y potente sistema que, sin embargo, se implementa en un grupo de
ordenadores, potencialmente dispersos en diversospases.Desarrolladoapartirde
1981 en la Universidad Vrije de Amsterdam, es un sistema de libre distribucin.
Est implementado en Orca, un lenguaje para programacin paralela en sistemas
distribuidos. No obstante, Amoeba es un completo sistema operativo (presenta
incluso una librera de emulacin POSIX), no simplemente un sistema de
comunicacionesdegrupo.Unaideasimilareslasoportadaporelserviciodeclusters
de Microsoft (MSCS) [Vogels98], pero en este caso la funcionalidad se escribe sobre
suomnipresentesistemaoperativo.Sinembargo,MSCSslosoportainicialmenteun
conjunto limitado de aplicaciones (servidores de ficheros, de mail electrnico, de
pginasWebybasesdedatos)ynicamentesobredosnodos.
4.1.2.Arjuna
Desarrollado desde 1987 en la Universidad de NewCastle upon Tyne, Arjuna
[Arjuna] se define como un sistema deprogramacinorientadoaobjetosquebusca
la simplificacin del proceso de desarrollo de aplicaciones distribuidas fiables.
Opera sobre el modelo cliente/servidor y puede ejecutarse sobre entornos
heterogneos, usando C++ como lenguaje de programacin. La fiabilidad la obtiene
mediante transacciones atmicas anidadas distribuidas. Es, por lo tanto, ms bien
unsistemadetransaccionesqueunsistemadecomunicacionesdegrupo.Dehecho,
se ha portado a CORBA, siendo compatibleconelserviciodetransaccionesdeesta
arquitectura.
Enestesistema[Parrington95],elestadodelosobjetosesadministradoporun
objetodelaclaseStateManager.Losobjetosseclasificancomo:
Recuperables: el StateManager trata de generar y mantener toda la informacin
necesariapararecuperarelestadodelobjetosistesecae.Estainformacinse
guardaenobjetosdelaclaseObjectState.
Recuperables y persistentes: son objetos recuperables cuyo ciclo de vida puede
exceder al de la aplicacin que los cre. En estos casos, el StateManager
intentarobtenerelestadoprevioantesdeactivarelobjeto.
Norecuperablesnipersistentes:elStateManagernoguardaningunainformacin
sobre estos objetos. Para simplificar el trabajo del StateManager, un objeto no
puedecambiarsutipoentiempodeejecucin.
Losobjetosrecuperablesdebenimplementartresmtodos:
boolean save_state (ObjectState &state, ObjectType oType);:elobjetosobreelque
el StateManager invoca esta operacin debe salvar su propio estado en el
parmetro de la clase ObjectState. Mediante el parmetro del tipo ObjectType,es
posible pasarle cierta informacin al objeto para que conozca el motivo de la
operacin.
boolean restore_state (ObjectState &state, ObjectType oType); : es la operacin
simtricaalaanterior.
const TypeName type () const; : devuelve el tipo como una cadena de caracteres,
usadosimplementeparaloscontrolesdeconcurrenciaypersistencia.
Elprotocolodereplicacinpordefectosebasaenunanicarplicaprimaria,
quesecomunicaconrplicasenbackup.Cuandounanuevarplicaseincluyeenel
grupo, puede recibir entonces automticamente el estado. Sin embargo, no se
puedenincluirnuevosmiembrosenelgrupomientrashayausuariosoperandosobre
l. Es decir, la transferencia de estado se realiza con la seguridad de que ningn
miembroprocesarningunaoperacinhastaquelatransferenciahayafinalizado,lo
quesimplificaenormementeelprotocolo.
Consecuentemente, las aplicaciones desarrolladas en este sistema se
bloquean durante la transferencia; a cambio, sta se realiza de una forma muy
simplificada, implementando en cada objeto dos operaciones bsicas de
almacenamientoyrecuperacindelestado.
4.1.3.Bast
Este sistema [Bast] es un framework de patrones para el desarrollo de
aplicaciones distribuidas tolerantes a fallos. Est enfocado [Garbinato97], ms que
en los algoritmos mismos que soportan el desarrollo de aplicaciones distribuidas
tolerantes, en el estudio de los patrones que facilitan el desarrollo de esas
aplicaciones:quabstraccionesresultanadecuadasparamodelarlafiabilidad,cmo
representarlas para promover diseos flexibles y cmo implementarlas para
promoverlareusabilidaddelcdigo.Lospatronesenlosqueseenfocaestesistema
estn relacionados conlosprotocolosdecomunicacionesmsqueconlaaplicacin
final:cmoimplementarprotocolosapartirdeunframework,conunospatronesde
diseo sobre esos protocolos bien especificados. Est desarrollado en Smalltalk, y
est siendo portado a Java. Como el sistema Phoenix, ha sido desarrollado en el
SwissFederalInstituteofTechnologydeLausanne.
4.1.4.UniversidaddeCornell:Isis/Horus/Ensemble/
Spinglass
Estos cuatro sistemas son la evolucin del sistema inicial propuesto y
desarrolladoporKenBirmansobresumodelodesincronavirtual.
El primer sistema, Isis [Isis], desarrollado desde 1983, implementaba una
coleccin de tcnicas para laconstruccindesoftwaredesistemasdistribuidoscon
un rendimiento eficiente, tolerante a fallos hardware y software, y explotando el
paralelismo de los sistemas [Birman85].Elplanteamientobsicofuedesuministrar
lasherramientasnecesariasparainterconectarcomponentesnodistribuidos,dando
paso a un sistema distribuido fiable, con herramientas para manejar datos
replicados, sincronizar operaciones distribuidas, recuperacin automtica tras
errores,yreconfiguracinautomticadelsistema.
Apartirdeunrediseodeestesistema,desde1993IsisevolucionaHorus
[Horus], una arquitectura de comunicaciones de propsito general con un soporte
avanzado para el desarrollo de aplicaciones distribuidas robustas [Renesse96]. Se
basa tambin en las comunicaciones de grupo, proporcionando a laaplicacinfinal
las primitivas de comunicaciones necesarias para desarrollar los requisitos de
fiabilidadalmnimocoste.Horusexistecomodossistemas:unaversininicialenC,
disponible comercialmente y gratuita para fines de investigacin, y una nueva
versinllamadaEnsemble.
Ensemble [Ensemble] es una versin de Horus escrita a partir de 1996 en
Ocaml, un dialecto de ML, y est disponible gratuitamente para todos los usuarios.
Como Horus, se dise para resultar independiente de la plataforma. Provee a las
aplicaciones de una librera de protocolos con la que construir rpidamente
aplicacionesdistribuidasfiables;stasregistranunaseriedeeventosconEnsemble,
y los protocolos de Ensemble gestionan el envo y recepcin fiable de mensajes,
transferencia de estado, seguridad, deteccin de fallos y la reconfiguracin del
sistema[Hayden98].TieneunainterfazaCdenominadaHot,ysobreestainterfazse
han desarrollado un conjunto de clases denominadas Maestro [Maestro], que
implementan un modelo de transferencia de estado que detallamos en el siguiente
captulo.TambinhandesarrolladounainterfazaJava,convistasatenerEnsemble
comounplug-inenNetscape.
Spinglass[Spinglass]esunproyectoiniciadorecientemente(1999),quetrata
de obviar las limitaciones del modelo de sincrona virtual en grupos con gran
cantidad de miembros. A diferencias de las tres generaciones previas comentadas,
presenta un enfoque diferente basndose en protocolos que soportan mensajera
multipuntocongarantasdefiabilidadprobabilsticas[Birman99].
4.1.5.Cactus
Cactus [Cactus] es unsubstratodecomunicacionesmodulardesarrolladoen
la Universidad de Arizona, soportando calidades de servicio que pueden cambiarse
dinmicamente.Sobreunprotocolobsicomultipuntousandoordenacincausal,se
aaden modularmente los protocolos de pertenencia a grupo (membership) y
ordenacintotal.HayversionesdisponiblesenC++yJavadeestesistema,queesla
continuacindeotroproyectodelamismauniversidad,llamadoConsul.
Cactus y Consul se basan en la utilizacin de mquina de estados replicados
[Schneider90]. Las aplicaciones se estructuran como mquinas de estado que
mantienen colecciones de variables de estado. Cada mquina de estado recibe
rdenes de otras mquinas de estado para modificar u obtenersusvariables.Estas
rdenessondeterministasyatmicasconrespectoaotrasrdenes,detalformaque
puededeterminarseelestadodeunobjetoexclusivamenteapartirdelasrdenesde
entrada.
Todo el sistema [Schlichting93] se desarrolla en torno a tres servicios:
mensajera multipunto, pertenencia a grupo y recuperacin (recovery). Este ltimo
servicioderecuperacineselencargadodesincronizaraunarplicaquesehubiera
cado con el resto de rplicas activas. Para ello usa una tcnica de checkpoints y
seguimiento de mensajes: cada rplica, sin necesidad de comunicarse con otras
rplicas,vaescribiendocheckpoints(instanciasdesuestado)yguardalosmensajes
en un sistema de almacenamiento estable. Tras un fallo, la rplica recupera el
ltimo estado almacenado, y se comprueban los mensajes procesados para
sincronizarlaconotrasrplicas.
Esta tcnica es rpida cuando las rplicas se caen durante cortos periodos
de tiempo, de otra manera resulta ms efectiva la transferencia desde otra rplica
activa.
4.1.6.Electra
Electra [Electra] fue probablemente el primer ORBquesoportdeunaforma
noestndarlaimplementacindeaplicacionesdistribuidasfiablessobreCORBA.Su
desarrollo se efectu sobre Isis y no se ha completado su porte a los sistemas
sucesores de aqul, Horus y Ensemble. La fiabilidad la obtiene a partir del sistema
de comunicaciones de grupo sobre el que se implementa (tericamente, cualquier
sistema que implemente el concepto de grupos con comunicaciones fiables provee
las primitivas necesarias para Electra). Implementa un protocolo propio de
transferencia de estado,independientedelosprotocolosdetransferenciaexistentes
enelsubstratodecomunicaciones.
EsteORB[Maffeis97]sobreIsisdefineunmecanismobsicodetransferencia
de estado, en la que el BOA (Basic Object Adapter) con el que trabaja (el POA,
Portable Object Adapter, es una estandarizacin bastante posterior a Electra) define
dosmtodosparacontrolarlatransferenciadeestado.Estosmtodossonvirtuales,
ydebenserimplementadosporlaclasefinalquees,porconsiguiente,unainstancia
delBOA,enloqueresultaunenfoquepocotradicional:
getState
setState
Ambos mtodos tratan el estado mediante el tipo genrico de datos CORBA
AnySeq. La transferencia puede realizarse en varios pasos. Para ello, los dos
mtodos incluyen una indicacin de finalizacin de la transferencia, que la
aplicacindeberellenarconvenientemente.Elprimermiembroqueseincluyeenun
gruponorecibeelestadodeotrosmiembros,eselnicocasoenqueunmiembrono
recibeunainvocacindesumtodosetState.
Tambin implementado sobre Isis, el mismo autor de Electra desarroll
CyberBus, un antecedente de iBus, donde la abstraccin de grupo con la que se
trabaja es mediante canales, a los que se pueden subscribir distintos miembros,
tanto servidores de datos, comoconsumidores.Deestaforma,permiteimplementar
un sistema de comunicaciones en grupo bajo el modelo de mensajera en lugar del
clsico cliente/servidor. En este caso, la clase de la aplicacin que soportan
tolerancia a fallos debe sobrecargar tres mtodos, que son invocados
automticamenteporelcanalalqueestnsuscritos:
obj_ask_state:elobjetoinvolucradodebedevolversuestadoasociado,empleando
eltipoCORBA::AnySeq.
obj_set_state:permitefijarelestadodeundeterminadoobjeto.
obj_load_state: se emplea para el primer objeto del grupo, de tal forma que no
recibaelestadodeotrosmiembrosypuedainicializarlodirectamente.
AlcontrarioqueenElectra,latransferenciaserealizaahoraenunsolopaso.
En ambos casos, el mecanismo de transferencia se basa en las listas de
grupo que Isis suministra, donde cada miembro tiene un rango determinado. Los
miembros ms antiguos presentan un rango inferior, con lo que Electra puede
emplearsiempreelmiembromsantiguopararealizarlatransferenciaalosnuevos
miembros.Estatransferenciaserealizadeformaautomtica,guiadaporelsoftware
quegestionaelgrupo.Durantelatransferencia,elsistemaquedabloqueado.
4.1.7.Ibus/MessageBus
DelmismoautorqueElectra,existedesde1996unaversincomercial[Ibus]
deunserviciobasadoenelserviciodemensajeraJavaJMS[SUN99]quepermiteel
desarrollo de aplicaciones distribuidas tolerantes a fallos, obtenindose esa
toleranciaconunasextensionesnoestndaralservicio.EsteservicioenJavanose
basaenunmodelocliente/servidor,sinoenunmodelodepublicacin/subscripcin,
donde las aplicaciones u objetos productores producen informacin en los canales
de comunicacin, y las aplicaciones subscriptas a esos canales reciben esa
informacin.Puestoquelainformacinfluyeporloscanalesdecomunicacin,noes
necesaria la localizacin exacta de los subscriptores o emisores, facilitndose su
migracinentredistintasmquinasyprocesos.ElJMSllamatpicosalosenlacesde
comunicacin; los canales son estos tpicos, a los que se aade una calidad de
servicio. Esta calidad de servicio, como ocurre en los grupos de Ensemble, se
construyesobrelabasedeunapiladeprotocolos;incluyendoelprotocoloadecuado,
se obtiene tolerancia a fallos mediante un servicio de miembros GMS. Tanto los
miembros que publican como los que subscriben pertenecen al mismo grupo y no
hayningnmecanismoespecficoparalatransferenciadeestadoentrelosemisores.
4.1.8.JavaGroups
Estesistema[JavaGroups],tambinprovenientedelaUniversidaddeCornell,
es un conjunto de herramientas Java que facilita el desarrollo de sistemas
distribuidos fiables. La abstraccin sobre la que trabaja es la de grupos de objetos,
que denomina canales; presenta tres implementaciones de canales; JChannel, no
fiable, EnsChannel, fiable, trabajando sobre Ensemble, e IbusChannel, tambin
fiable,trabajandosobreIbus.
Esta implementacin de un sistema de grupo de comunicaciones no fuerza
unatransferenciadeestadocadavezqueunnuevomiembroseincluyeenelgrupo,
oempleandolanotacindelsistema,enelcanal.Esfuncindeestemiembrolade
dirigirse a otro miembro para solicitar el estado, pudiendo, adems, hacerlo en
cualquiermomentodesuciclodevida;disponeparaellodedosmtodos:
GetState: devuelve el estado de un miembro, normalmente del ms antiguo, el
coordinador.
GetStates:devuelveelestadodetodoslosmiembros.
Esta solicitud de estado es asncrona; el objeto que la solicita recibir
eventualmenteunoomseventosSetState.
Elprotocolodetransferenciadeestadotienelossiguientespasos:
Todoslosmiembros,incluyendoelquelosolicita,recibenunmensajeparahacer
una copia de su estado. Antes de copiarlo, encolan los mensajes sucesivos que
les lleguen, procesndolos nicamente cuando haya completado la copia de su
estado.
Unmiembro,posiblementeelmsantiguo,recibeunasolicitudparadevolversu
estado.Alternativamente,estasolicitudpuededirigirseatodoslosmiembros.
El nuevo miembro recibe el estado y procesa los mensajes encolados, tras los
cualespuedeempezararesponderanuevosmensajes.
La versin actual de JavaGroups (0.6.6) slo soporta la transferencia de
estado cuando emplea su propia implementacin de canal, JChannel. Las
implementaciones sobre Ensemble e Ibus no la soportan. Adems, el protocolo
expuestoprecisaqueelcanalpresenteordenacintotaldelosmensajesmultipunto.
Bajo JavaGroups, un objeto que vaya a intervenir en una transferencia de
estado debe soportar la interfaz StateExchange, con tres mtodos que permiten
procesarcadaunodelospasosdelprotocoloexplicado:
voidSaveState();:guardaelestadoenunacopiainterna.
voidObjectGetState();:devuelvelacopiadelestadoalmacenadapreviamente.
voidSetState(Objectnew_state);:transfiereelestadoalmiembro.
Esteesquemapermiteunatransferenciaquesesimplificaenormementepara
la aplicacin final; a cambio, le otorga muy poca flexibilidad, a la vez que impone
requisitosadicionales,comoeslaordenacintotal.
4.1.9.JGroup
El proyecto JGroup [JGroup] de la Universidad de Bolonia, se define como
una integracin de objetos distribuidos con la tecnologa de grupos, dando paso al
paradigmadegrupos de objetos.BasadoenJava,seincluyedentrodeotroproyecto
llamado Relacs [Relacs], para el desarrollo de herramientas con soporte sistemtico
deserviciosyaplicacionesparticionablesenentornosdistribuidosasncronos.
Este sistema [Montresor98] se deriva del modelo de invocacin remota de
Java, emplendolo directamente para las comunicaciones internas y usando un
modelo de arquitectura parecido, pero extendido a grupos. Contiene un compilador
propio llamado dmic paralelo al empleado en RMI, rmic, y un registro de servidores
especfico para grupos llamado dregistry. Si en RMI los objetos remotos deben
implementar una interfaz Remote, en JGroups la interfaz se llama
ExternalGMIListener para su interaccin con clientes e InternalGMIListener para la
interaccin con los dems miembros del grupo; las siglas GMI significan Group
MethodInvocation:invocacindinmicadegrupos.
Unadelasprincipalescaractersticasdeestesistemaeslaexposicindelos
problemas de red a la aplicacin, bajo la suposicin de que sta tiene un mejor
conocimientodelgrupoparapodermanejaresosproblemas.Esteplanteamientoest
motivado en que este sistema emplea el modelo de sincrona virtual extendido
[Babaoglu96],soportandolaexistenciadevariasparticionesactivas;enestecaso,es
necesario que cuando dos particiones se unifican de nuevo, puedan homogeneizar
susestados,yesaesunalabortotalmentedependientedelaaplicacin.
La re-unin de particiones la realiza el servicio llamado SMS, state merging
service, y es necesario que en ese caso se implemente la interfaz MergingListener,
quedefinedosoperaciones:
ObjectgetState(MemberId[]dests):obtieneelestadodeunaparticin.
void putState(Object status, MemberId[] sources); informa del estado a la otra
particin,quedebereconstruirunestadohomogneo
En estas operaciones, la listas de identidades son las de losmiembrosdela
particin que se unifica. La operacin getState se invoca exclusivamente sobre un
miembrodeunaparticin,alqueseconsideracoordinador.
4.1.10.Nile
El proyecto National Challenge Computing Project [Nile] se desarroll
inicialmente para una aplicacin especfica (CLEO High Energy Experiment), donde
deba crear un sistema autogestionado, tolerante a fallosyheterogneoconcientos
de estaciones de trabajo que accedieran a una base de datos superior a los cien
terabytes, distribuida en distintas localizaciones de Canad y Estados Unidos.
Aunque el dominio de este sistema es ms extenso, el de aplicaciones fcilmente
paralelizables [Marzullo96] independientes de la localizacin de los recursos y los
datos,nopuedeconsiderarseunsistemagenricodecomunicacionesengrupo.Est
desarrolladoenJavaporlaUniversidaddeCornell.
4.1.11.Phoenix
Phoenix [Phoenix] es un conjunto de herramientas para la construccin de
aplicaciones distribuidas tolerantes a fallos a gran escala. Como Bast, ha sido
desarrollado en el Swiss Federal Institute of Technology de Lausanne, pero no esun
sistemadelibredistribucin.
Este sistema [Malloth96] trata la transferencia de estado como un problema
desincronizacindeunmiembroqueseuneaungrupoydeberecibirelestadode
otro miembro, no pudiendo procesar ninguna peticin de servicio en tanto no se
completeesasincronizacin.
La abstraccin de grupo que realiza Phoenix incluye tres tipos de objetos:
receptores, clientes, y miembros. Hay una relacin de herencia entre estos objetos,
detalformaqueunclienteesunreceptoryunmiembroesuncliente.Unreceptor
puedeunirseyexcluirsedeungrupo,yrecibirinformacindeste.Unclientepuede
adems recibir los cambios de vistas as como enviar solicitudes de servicio.
Finalmente, un miembro puede enviar tambin mensajes multipunto en el interior
de un grupo. Cuando un cliente realiza una solicitud de servicio, la realiza a un
nicomiembroque,asuvez,envaelmensajemultipunto.
La transferencia de estado la realiza automticamente Phoenix en cuanto
detecta un nuevo miembro, pero no ante clientes o receptores; en ese momento,
invoca la operacin GetState sobre un miembro antiguo del grupo,elcualresponde
con una cadena de bytes, que es transferida tal cual al nuevo miembro, que debe
soportarlaoperacinsimtricaPutState.
Como conclusin, la transferencia es controlada automticamente,
seleccionndose un miembro antiguo como coordinador de la transferencia, la cual
se realiza en un solo paso. Esta transferencia se considera atmica en el nuevo
miembro,quenorecibirningnmensajeentantonosesincroniceconlasdems
rplicasactivas.
4.1.12.RMP
El nombre de este sistema [RMP] es un acrnimo para Reliable Multicast
Protocol. Su enfoque es el rendimiento del servicio de mensajera, y provee un
servicio de mensajera multipunto fiable, atmico y con ordenacin total sobre IP
multipunto.SehadesarrolladoenlaUniversidaddeIllinoisatUrbana-Champaign.
4.1.13.Spread
Spread [Spread] es otro conjunto de herramientas, con soporte de
comunicaciones de grupo para la creacin de aplicaciones distribuidas en LANs y
WANs. Su dominio bsico de aplicaciones son las aplicaciones colaborativas,
servidores fiables, transmisiones multimedia y sistemas de grupos en general
(groupware). Para ello soporta todos los niveles de mensajera y ordenacin, bajo el
modelo de sincrona virtual extendida. Las aplicaciones la usan como una librera
con la deben enlazarse; el lenguaje de programacin empleado es C, aunque
presenta tambin una interfaz Java. Est siendo desarrollando actualmente en la
UniversidadJohnsHopkins,Baltimore.
Spread [Amir98] no presenta un soporte especfico para la transferencia de
estado. La interfaz Java presenta dos mtodos para la recepcin de mensajes:
membershipMessageReceived y regularMessageReceived pero ningn mtodo
especfico para salvar o recuperar el estado. La aplicacin debe construir su propio
sistema de transferencia y usar el envo normal de mensajes. Cuando un miembro
antiguo perciba la inclusin de un nuevo miembro (lo recibir en un mensaje a
travs del mtodo membershipMessageReceived) deber construir un mensaje de
estadoqueelnuevomiembrorecibiratravsderegularMessageReceived.
La transferencia de estado queda entonces como una responsabilidad de la
aplicacin, que deber implementar todos los detalles necesarios para que los
nuevos miembros sincronicen sus estados con los miembros antiguos. Puesto que
soporta sincrona virtual extendida, es tambin responsabilidad de la aplicacin el
desarrollar el protocolo de conciliacin de los estados de los miembros cuando se
renentrasunaparticin.
4.1.14.Totem
Desarrollado en la Universidad de Santa Barbara, California, Totem [Totem]
es un conjunto de protocolos de comunicaciones que soporta la construccin de
sistemas distribuidos tolerantes a fallos. Tiene dos caractersticas claves: el empleo
de mensajes multipunto con ordenacin total en lugar de ordenacin causal, y el
empleo del modelo de sincrona virtual extendida, permitiendo de esta manera que
distintas particiones de una aplicacin se mantengan operativas, en tanto la
consistencia requerida seacorrecta.Elfavorecerlaordenacintotalsebasaenuna
fuerte optimizacin del sistema de mensajera que hace innecesario el empleo de
ordencausal.
Enestesistema[Moser95],elmodeloempleadoparaelenvodemensajeses
la creacin de un anillo lgico entre los componentes del grupo, anillo por el que
circula un testigo con losmensajes.Paraobtenerunabuenaeficiencia,seemplean
lascaractersticasdemensajeramultipuntodisponiblesenredesderealocal.
Esunodelospocossistemasqueenfocalatransferenciadeestadocomoun
problemaprioritario.Alsoportardistintasparticiones,debepermitirlareconciliacin
de estados inconsistentes, lo que puede implicar el envo de mensajes con largas
porciones del estado. Define cuatro opciones para resolver el problema de la
transferencia:
Pararelsistema,quesedesbloqueatraselenvodelestado.
Todoslosprocesosmantienencheckpointsyalmacenanlosmensajesprocesados
desde el ltimo checkpoint. La transferencia de estado se resuelve con el envo
del ltimo checkpoint y de todos los mensajes almacenados tras l. Aunque
simple, puede suponer el empleo de grandes cantidades de espacio para
almacenar la informacin temporal y cada proceso debe destinar recursos para
almacenarloscheckpointseirguardandolosmensajes.
Slounproceso,elquedebeenviarlatransferencia,quedainoperativomientras
realiza la transferencia. Una posibilidad en este esquema es que ese miembro
realice primero una copia interna del estado, que emplea para la transferencia,
quedandoentoncesoperativomsrpidamente.
Elmiembroqueenvaelestadopermaneceoperativo,manteniendounarchivode
los cambios efectuados en el estado durante la transferencia. La transferencia
incluye, consecuentemente, el estado y uno o varios mensajes posteriores
incluyendoloscambiosefectuados.
Con este esquema, la primera opcin es vlida cuando el estado a enviar es
pequeo y el sistema no es crtico en el tiempo; en otro caso, es mejor tomar la
tercera opcin. La ltima opcin es muy atractiva, pero supone una mayor
complejidadenlaaplicacinfinal.
4.1.15.Transis
Transis [Transis], es una implementacin de la Universidad Hebrea de
Jerusalndeungrupoeficientedecomunicacionesparaaltadisponibilidad.Aligual
que en Totem, Transis permite el particionado de grupos y da soporte a la
transferenciadeestado.Losmiembrosdelgruposonprocesos,aunqueunainterfaz
Javapermitelaabstraccindeclases.
En Transis [Dolev96], la transferencia de estado es todava una
responsabilidad de la aplicacin, que debe realizar los pasos pertinentes para
sincronizar correctamente los estados. De esta manera, para una transferencia
simple (sin incluir particiones yreconciliacindeestados),susautoresproponenel
siguienteprotocolo:
Losmiembrosdejandeenviarmensajes(losmensajesquedanbloqueados).
Cada miembro enva un mensaje de parada que emplear el miembro que debe
enviar el estado para saber cundo ha procesado todos los mensajes de un
miembro.
Cuando el miembro que debe enviar el estado recibe el mensaje de parada de
todos los dems miembros, enva el estado en uno o varios mensajes, al nuevo
miembro.
Trasconcluirlatransferencia,sedesbloqueanlosmiembrosysereiniciaelflujo
demensajes.
Por consiguiente, y tal como ocurre con Totem, se considera prioritario el
problemadelatransferencia,aunquesigueestandolaresponsabilidaddelprotocolo
de transferencia en la aplicacin, que debe escoger el mtodo ms apropiado para
realizarlasincronizacindeestados.
4.1.16.xAmp
Estesistema[xAmp],desarrolladodesde1991enlaUniversidaddeLisboa,es
un acrnimo de eXtended Atomic Multicast Protocol. Bsicamente, es un sistema de
comunicaciones de grupo que proporciona primitivas que facilitan el desarrollo de
aplicaciones distribuidas fiables. Este servicio [Rodrigues92] de grupo de
comunicaciones fue desarrollado siguiendo el modelo de Isis, que encapsula en el
subsistema de comunicaciones un juego de primitivas que soportan diferentes
calidades de servicio, cuyo uso facilita el desarrollo de aplicaciones distribuidas
fiables.
Est desarrollado en C, presentando al usuario un grupo de primitivas que
soportanelconceptodegruposdemiembros.Deestamanera,hayprimitivasconlas
queunirseosalirsedegrupos(xampGroupOpen,xampGroupClose)yenviarmensajes
al grupo con distintas condiciones de atomicidad, fiabilidad y ordenacin
(reliableSend,atomicSend,).Laaplicacindebesuministrarasuvezfuncionescon
las que manejar los eventos del grupo: viewHandler, para las notificaciones de
cambios de vistas, confHandler, para recibir confirmaciones de solicitudes (como la
de incluirse en un grupo) y dataHandler, donde se reciben mensajes de otros
miembrosdelgrupo.
No se contempla especficamente la transferencia de estado, dejando como
responsabilidaddelaaplicacinelprotocolodelatransferencia.
4.2.TransferenciadeestadoenMaestro
Maestro es un conjunto de clases C++ que permiten crear una abstraccin de
objetos sobre los sistemas de Horus y Ensemble. Existe una capa intermedia entre
estossistemasyMaestro,denominadaHot,queesunainterfazC;haydosinterfaces
Hot, una para Maestro y otra para Ensemble, pero una nica implementacin de
Maestro. Aunque estos sistemas definen un protocolo de transferencia de estado
propio, Maestro implementa uno independiente, que es el que se detalla aqu. Esta
explicacinincluyelaversin0.51sobreEnsembleylaevolucinposteriorrealizada
parasolventarloserroresdetransferenciadeestadodelaprimera.
Sensei se inici como una solucin a los problemas de transferencia en
Maestro, y desarrollamos un conjunto substituto de clases que, funcionando sobre
Ensemble-Hot, implementa parte de la funcionalidad que requerimos para un
protocolo de transferencia de estado completo. sta es la razn por la que
detallamosesteprotocolo,alserlabasedelosdesarrolladosenestamemoria.
4.2.1.Versin0.51
La clase bsica es Maestro_GroupMember, con la que es posible especificar la
calidad de servicio que un miembro de un grupo usar (todos los miembros deben
emplear la misma calidad de servicio). Esta calidad de servicio se especifica como
una cadena de caracteres donde cada propiedad viene separada por ':', como por
ejemplo "Gmp:Sync:Heal:Switch:Suspect:Flow:Primary". Dos operaciones, join y
leave permiten la inclusin y exclusin del miembro en el grupo definido, y cada
objeto slo puede incluirse en un grupo. Si el objeto es el primer miembro de un
grupo, ste se crea automticamente. Mediante varias operaciones send y cast, es
posibleenviarmensajespuntoapuntoomultipunto,queserecibenconlosmtodos
grpMemb_ReceiveSend_CallbackygrpMemb_ReceiveCast_Callback,respectivamente.
Cuando se produce un cambio de vista, Maestro invoca [figura 4.1] tres
operaciones:
grpMemb_Block_Callback,parainformarquelavistahasidobloqueada.
grpMemb_ViewMsg_Callback, con la nueva vista a instalar, que se invoca
exclusivamente sobre el miembro con menor rango de la vista y que en la
notacin de Maestro se denomina coordinador. Este coordinador puede incluir
alguna informacin tras una llamadaaestemtodo,queesentoncespropagada
atodoslosmiembrosconelsiguientemtodo.
grpMemb_AcceptedView_Callback. Este mtodo se invoca sobre todos los
miembros con la nueva vista a instalar, as como con la informacin que
transmitaelcoordinadordelavista.Lavistacontienelalistaordenadadetodos
losmiembrosdelgrupo,juntoaalgunainformacinadicional.
Esta clase no proporciona ningn soporte de transferencia de estado. Para
obtenerlo, se usa unaclaseespecializada,Maestro_ClSv,quemantieneunarelacin
deherenciaconlaanterior.Cuandosecreaunobjetodeestetipo,puedeindicarse
siperteneceralgrupocomoclienteoservidory,enesteltimocaso,culeselnivel
deproteccindurantelatransferencia:
MAESTRO_NO_XFER:nohaytransferencia.
MAESTRO_FREE_XFER:haytransferencia;sepuedeenviartodotipodemensajes
mientrasdurelatransferencia.
MAESTRO_PROTECTED_XFER: hay transferencia, y los nicos mensajes
permitidos son los de la transferencia y los considerados seguros para aquella.
Para realizar esta distincin, cada mensaje incluye un atributo fijado por su
emisor que indica cundo se considera seguro procesar ese mensaje durante la
transferencia.
MAESTRO_ATOMIC_XFER: slo los mensajes de transferencia de estado estn
permitidosdurantelatransferencia.
Figura 4.1.Mensajes enMaestro_GroupMember enun cambio devista
Coordinador:Maestro
_GroupMember
Miembro1:Maestro_
GroupMember
Miembro2:Maestro_
GroupMember
:MAESTRO
grpMemb_Block_Callback()
grpMemb_ViewMsg_Callback()
grpMemb_AcceptedView_Callback()
Puestoqueestaclaserealizaladistincinentreclienteyservidor,seincluyen
nuevosmtodosparaenviarmensajessloalosservidores(scast),aunquesepuede
especificarunalistadeclientesquerecibirntambinestemensaje.
La vista que se instala diferencia tambin una lista para los servidores y otra
para los clientes; si debe producirse una transferencia de estado, la vista se
considera de transferencia de estado y, como tal, se indica en la vista; cuando la
transferencia finalice, se instalar una nueva vista. Cada miembro recibe tambin,
con la vista, su papel durante la transferencia: si es emisor, receptor o no se
involucraenningunatransferencia.
Laimplementacindetransferenciadeestadosigueelparadigmapull:elnuevo
miembro debe pedir a miembros antiguos el estado, siendo posible pedirlo por
porciones. Es tambin responsabilidad del nuevo miembro decidir cundo ha
finalizado la transferencia. El nuevo miembro [figura 4.2] pedir el estado a un
determinado servidor invocando la operacin askState definida en Maestro_ClSv,
pudiendo incluir un mensaje donde especifica la porcin de estado requerida. El
servidor recibe la notificacin de la peticin de estado con askState_Callback y
deber responder, eventualmente, usando el mtodo sendState. El miembro que
esperaelestadolorecibeconrcvState_Callback,pudiendosolicitarentoncesnuevas
porciones del estado o, si considera que la transferencia hafinalizando,notificando
esteeventoconelmtodoxferDone.
Durante la transferencia, los mensajes considerados no seguros son
introducidos en una cola y sern enviados cuando finalice la transferencia. Este
encolamientolorealizaMaestrodeformaautomtica.
Figura 4.2.Mensajes enMaestro_ClSv en unatransferencia de estado
JoiningMember
:Maestro_ClSv
JoiningMember':
Maestro_GroupMember
:MAESTRO StateMember:
Maestro_GroupMember
StateMember':
Maestro_ClSv
askState()
send()
grpMemb_ReceiveSend_Callback()
askState_Callback()
sendState()
send()
send()
rcvState_Callback()
Este diseo proporciona una gran flexibilidad alaaplicacin.Latransferencia
sepuedehacerenporciones,inclusopodranrequerirsesimultneamentediferentes
porciones a distintos miembros con estado. Si es preferible que la transferencia la
realice un miembro con estado determinado, el coordinador puede enviar esta
informacin cuando la vista se instale, ya que la vista se enva primero al
coordinador con clSv_ViewMsg_Callback, que la devuelve a Maestro junto a un
mensaje que ser retransmitido a todos los miembros con el mtodo
clSv_AcceptedView_Callback.Ylaaplicacinpuededecidirqumensajessonseguros
para el estado y pueden ser enviados durante la transferencia. Como no todos los
mensajes son bloqueados bajo este esquema, el orden de procesamiento no ser el
especificado por los requisitos de la aplicacin. Adems, como los mensajes no son
bloqueados en recepcin, los mensajes provenientes de la vista anterior s sern
recibidosporlosmiembros.
Maestro_ClSvdaposiblementedemasiadaflexibilidadalaaplicacin,quedebe
decidir qu miembro le transmite el estado o qu hacer si se cae ese miembro
durante la transferencia. Por esta razn, existe una tercera clase denominada
Maestro_CSX,subclasedelaanterior,quesimplificalatransferenciaconlasiguiente
interfaz[figura4.3]:
stateTransfer_Callback: la invoca automticamente Maestro sobre un miembro
nuevo cuando debe iniciar una transferencia. Hasta el momento, slo se ha
consideradolainsercindenuevosmiembrosenelgrupo,peroestasoperaciones
son tambin invocadas si se produce una unin de dos particiones del mismo
grupo. De hecho, tras la unin de particiones, antiguos miembros con estado
Figura 4.3.Mensajes enMaestro_CSX en unatransferencia de estado
:Maestro_CSX :Maestro_ClSv :MAESTRO :Maestro_ClSv :Maestro_CSX
stateTransfer_CallBack()
getState()
askState( )
askState_Callback()
askState_Callback( )
sendState()
sendState()
rcvState_Callback()
gotState_Callback()
pueden pasar a ser considerados como miembros sin estado y precisar una
transferencia.Maestroasociaacadatransferenciaunaidentidad,porloquesise
cae el miembro que transfiere el estado a un determinado nuevo miembro, este
ltimo recibir de nuevo una notificacin stateTransfer_CallBack con una nueva
identidaddetransferencia.
getState: tras recibir una notificacin para que se inicie una transferencia, el
nuevo miembro solicita el estadoconestemtodo.Debeespecificarlaidentidad
de la transferencia, pero no debe preocuparse por encontrar un miembro con
estado que se lo suministre, pues est implcito con la identidad de
transferencia. Aunque se puede solicitar el estado en porciones, esta operacin
noesreentrante,esdecir,debersolicitarsesecuencialmente.
askState_Callback: el miembro con estado es notificado a travs de este mtodo
para enviar la porcin de estado requerida, respondiendo con mensajes
sendState.
sendState:envaelestado,ounaporcindeste.
gotState_Callback:elnuevomiembrorecibeelestadoconestemtodo,pudiendo,
acontinuacin,solicitarnuevasporcionesdeestado.
xferCanceled_Callback: este mtodo permite saber al nuevo miembro que la
transferencia en curso ha sido cancelada. Posteriormente, recibir una
notificacinparainiciarunanuevatransferencia.
xferDone: el nuevo miembro invoca este mtodo cuando considera finalizada la
transferencia.
resetState:reinicializaelestado.
Esta clase simplifica, por lo tanto, las transferencias de estado en aquellas
aplicacionesquenorequieranespecialescondicionesdetransferencia.
Sin embargo, la razn por la que esta transferencia de estado no funciona en
todos los casos es por un problema que proviene de la clase inicial,
Maestro_GroupMember, que precisamente es la nica que no soporta transferencia.
En esta clase, se escoge al primer miembro de la vista y se le enva la nuevavista;
ste la devuelve junto con un mensaje que es luego retransmitido a los dems
miembros.Estemensajeeselutilizadoporlassubclasesparaenviarlainformacin
extendida de vista: la listadeservidoresylalistadeclientes.Sielprimermiembro
de la lista es un miembro nuevo en el grupo, la vista que enviar es una donde
ningn miembro tiene estado, pues no tiene constancia de que hubiera ningn
miembro con estado: es una situacin equivalente a un grupo que se crea
inicialmente con n miembros. En estas condiciones, decidir que no hace falta
realizarningunatransferenciayelprotocologeneralfalla.
La base de este problema se encuentra enunasuposicinerrnea:lalistade
miembros viene ordenada, siendo el miembro ms antiguo el de menor rango. Esta
suposicin era vlida con Horus, pero no lo es con Ensemble, donde el primer
miembrodelalistapuedeserelmiembrorecinincorporadoalgrupo.
4.2.2.Versin0.61
A partirdelaversin0.60,seresolvielproblemaqueplanteabalaslistasde
miembros cuyo orden difera en cada vista. El mtodo empleado es que todo
miembroconestadoenveunmensajemultipuntoconsuestado.Pararesolvercul
es el estado ms actualizado, los estados se asocian a un nmero de versin dado
porelpar{nmerodemensajesrecibidos,nmerodevistasaceptadas}.Cuandoun
servidor recibe un mensaje de estado actualiza el suyo propio si observa que es
necesario.
Deestaforma,elprotocolosesimplificaenormemente,yseejecutaenunasola
fase, facilitando adems el problema de conciliacin de estados en caso de
particiones. El rendimiento que se obtiene es aceptable si los cambios de vista son
poco frecuentes, no hay muchos miembros y el estado es pequeo. Toda la
flexibilidad que ofreca el anterior protocolo se pierde, pero el equipo de Ensemble
haba comprobado que la mayora de los usuarios de Maestro caan en la categora
delasaplicacionescuyorendimientobajoelnuevoprotocoloeraaceptableyquese
beneficiabandelasimplicidaddelnuevoesquema.
Bajoestascondiciones,lasclasesMaestro_ClSv yMaestro_CSXnoseemplean;
en su lugar se utiliza Maestro_GroupListener, que implementa dos mtodos bsicos:
getStateysetState.
4.3.CORBA
La ltima especificacin de CORBA soporta tolerancia a fallos mediante una
especificacindenominadaFault Tolerant CORBA Specification v1.0[OMG00],queno
tiene an el respaldo de una distribucin comercial compatible. Por esta razn
puedenesperarsecambiosenlaespecificacin,segnseadquiereexperienciaconla
implementacin. Adems, la definicin de la arquitectura incluye inicialmente la
posibilidad de extensiones propietarias a la especificacin, lo que limita la
interoperabilidadentredistribuciones.
La tolerancia a fallos se consigue mediante la redundancia de objetos,
introducindose una referencia especial a grupos de objetos, IOGR (Interoperable
Object Group Reference),nodefinidaenlaespecificacinCORBAbsica.Cadagrupo
sedefineconunconjuntodepropiedadesdetoleranciaafallos,como:
Estilo de replicacin: puede ser COLD_PASSIVE, WARM_PASSIVE, ACTIVE,
STATELESS, ACTIVE_WITH_VOTING. La especificacin actual no soporta este
ltimoestilo.
Nmeroinicialderplicas.
Mnimonmeroderplicas.
Tipo de pertenencia a grupo (membership style): puede ser controlada por la
infraestructura de CORBA o controlada por la misma aplicacin, segn se
necesiteunmayoromenorgradodetransparencia.
Estilo de consistencia: la consistencia puede estar tambin directamente
controladaporlainfraestructuraoporlapropiaaplicacin.
En los grupos directamente controlados por CORBA (infrastructure-controlled
membership), la replicacin de objetos resulta substancialmente transparente a la
aplicacin: la infraestructura crea nuevas rplicas o elimina miembros de forma
automtica, aunque la aplicacin an tiene determinado control sobre estas
operaciones, violando en ese caso la transparencia. En los grupos directamente
controlados por la aplicacin (application-controlled membership), es la aplicacin la
que debe crear las nuevas rplicas e incluirlas en el grupo, as como eliminar
miembrosdelgrupo.
Esta arquitectura se muestra en la figura 4.4; dos servidores se encuentran
replicados en dos mquinas diferentes. Los clientes acceden simultneamente a
ambosalemplearsuIOGR.Laaplicacinsolicitalacreacindeunobjetoreplicado
invocando la operacin create_object sobre el Replication Manager, o controlador de
replicacin, que invoca a su vez al GenericFactory, o factora genrica, que
transforma esa solicitud en nuevas invocaciones a las factoras particulares que
residen en cada mquina. El nmero de factoras invocadas, as como su
Figura 4.4.Arquitectura de tolerancia a fallos enCORBA
Generic
Factory
Generic
Factory
Replication,
Property,
ObjectGroup
managers
Replication,
Property,
ObjectGroup
managers
Fault
Notifier
Fault
Notifier
notifications
Fault
Detector
Fault
Detector
ORB
Logging Recovery
Factory
Fault
Detector
Server1
Host1
ORB
Logging Recovery
Factory
Fault
Detector
Server2
Host2
ORB
Client
create_object()
create
object()
localizacin, es dependiente de las propiedades del grupo. La aplicacin puede, por
otro lado, acceder directamente al controlador de grupos de objetos
(ObjectGroupManager) invocando operaciones como create_member, add_member o
remove_member y teniendo de esta manera ms control sobre la adicin y
eliminacin de miembros, as como sobre su localizacin. Estos controladores se
encuentran replicados sobre diferentes mquinas, obtenindose as uno de los
requisitos de la especificacin: que no haya un nico punto de fallo en todo el
sistema. De la misma forma se encuentra replicado el notificador de fallos (Fault
Notifier)yeldetectordefallos.
Slo en los grupos activos todos los miembros responden a cada peticin de
servicio; si se definen como pasivos, un nico miembro, definido como primario,
recibelaspeticionesyes,asimismo,elquelasresponde;siestemiembroprimariose
cae, uno de los miembros pasivos se promociona a primario. Cuando el estilo de
consistenciasehadefinidocomocontroladoporlaaplicacin,elmiembropasivoes
automticamente definido como primario y es responsabilidad de la aplicacin el
alcanzar la consistencia de estados. Sin embargo, si es controlada por la
infraestructura,entranenfuncionamientolosmecanismosdeLoggingAndRecovery.
Bajo estos mecanismos, todos los mensajes que son enviados al miembro primario
son guardados para poder ser recuperados ms tarde si hace falta reconstruir el
estado. Peridicamente, estos mecanismos invocan el mtodo get_stateenlarplica
primaria, que debe soportar la interfaz Checkpointable, de tal forma que la
reconstruccin del estado no tenga que pasar por el procesado de todos los
mensajes;cuandolarplicapasivasepromocionaaprimaria,recibeelltimoestado
almacenado mediante la operacin set_state y, a continuacin, recibir todos los
mensajesqueelanteriormiembroprimarioprocesantesdecaerse,garantizndose
as la consistencia de sus estados. Es por tanto necesario que la aplicacin sea
determinista; obviamente, si el grupo es STATELESS, estos mecanismos no son
necesarios.Elintervaloconqueseobtieneelestadodelaaplicacinesconfigurable.
La diferencia entre grupos pasivos fros ocalientesesqueenlosprimeros,los
miembros pasivos reciben slo el estado cuando se promocionan a primarios. Si el
grupo se ha definido como WARM_PASSIVE, esta transferencia se realiza con cada
operacin.Enamboscasossegarantizaquealfinaldecadatransferenciadeestado,
cada miembro del grupo involucrado en la transferenciatengaelmismoestadoque
presenta o presentaba el miembro primario. En el caso de grupos activos, la
consistencia de estado requiere que este estado sea el mismo tras cada peticinde
servicio,porloqueprecisandeunsistemafiabledecomunicacionesmultipuntobajo
elmodelodesincronavirtual.Elparticionadodelaredy,porlotanto,delgrupono
se soporta, es decir, no se incluye el modelo de sincrona virtual extendida en la
especificacin.
La replicacin activa garantiza una rpida respuesta en caso de cada de
miembros.Lapasivafraresultamscmodadeempleary,dehecho,puederesultar
completamente transparente, pero requiere de mayores tiempos de espera sisecae
el miembro primario, mientras se reconstruye el estado anterior. En el caso de
grupos pasivos calientes, la promocin a primario es inmediata pero, puesto que el
estadosetransfiereconcadaoperacin,resultaefectivaslocuandolatransferencia
delestadonoimplicamsrecursosqueelprocesadodecadamensaje,queeselcaso
deestadospequeos,principalmente.
LainterfazCheckpointablesedefinecomo:
interfaceCheckpointable{
Stateget_state()raises(NoStateAvailable);
voidset_state(inStates)raises(InvalidState);
};
La especificacin define asimismo una segunda interfaz para acelerar el
procesodealmacenamientoyrecuperacindeestadoencasodeestadosgrandes.
interfaceUpdateable:Checkpointable{
Stateget_update()raises(NoUpdateAvailable);
voidset_update(inStates)raises(InvalidUpdate);
};
Estainterfaznoimplicaqueelestadosepuedatransferirenvariospasos,pues
laprimeraoperacinsiguesiendoget_state,quedeberetornarelestadocompleto.La
recuperacin del estado involucra, en este caso, una operacin set_state, seguida
porunnmeroindeterminadodeoperacionesset_updateyunaseriedemensajesya
procesadosporelanteriormiembroprimario.
La figura 4.4 muestra dos de los componentes deestaarquitectura,Loggingy
Recovering (traceado y recuperacin), que residen por debajo del ORB.
Consecuentemente, esta especificacin no define un servicio CORBA genrico que
pueda instalarse sobre cualquier ORB y el servicio ser, al menos inicialmente,
dependiente de la distribucin empleada, en lo referente al lado servidor. Adems,
todoslosobjetosreplicadospertenecientesaunmismodominiodebenresidirsobre
ORBs del mismo distribuidor. En el lado cliente, este servicio afecta y modifica la
especificacinglobalCORBA,alintroducirlareferenciadegrupos(IOGR)porloque
clientes que residan sobre previos ORBs no participarn en los beneficios de la
toleranciaafallos.Estosclientespuedenaninvocarlosserviciossobreunodelos
servidores, pero la solicitud no se dirigir a los dems servidores replicados, por lo
quesiaquelservidorhacado,elclienteverdirectamenteelfallo.SiestosORBsno
disponen de todas las caractersticas necesarias para soportar como clientes la
toleranciaafallos,estodavaposiblequepuedanobtenerdelIOGRlasreferenciasa
los servidores replicados y, en caso de fallo de uno, reintentar la solicitud a otros
servidores,conloqueobtiene,almenos,soporteparcialdetoleranciadefallos.
4.4.Conclusiones
Elmodelodesincronavirtualimponelatransferenciadeestadocomounade
las propiedades inherentes al sistema. No define, sin embargo, restricciones o
requisitos sobre cmo realizar esa transferencia. Aun as, hay sistemas de
comunicaciones fiables de grupo, como xAmp, Transis oSpread,quenolasoportan
internamente.
La transferencia de estado puede desarrollarse externamente al sistema de
comunicaciones en grupo, utilizando las primitivas de comunicaciones que ste
soporta. Sin embargo, como demostramos en un captulo posterior, el modelo de
sincrona virtual puede respetarse en estos casos slo cuando el sistema de
comunicaciones exterioriza parte de sus comunicaciones internas. Ms
precisamente,serequierequeestesistemainformealosmiembrosdelgruponoslo
deloscambiosdevistas,sinotambindelbloqueodeestasvistascuandoseinician
las comunicaciones internas para acordar una nueva vista. Varios de los sistemas
expuestos en esta seccin soportan este evento incluso cuando ya soportan
internamente la transferencia de estado y a pesar de no ser uno de los eventos
definidosenelmodelodesincronavirtual.
En el caso de JavaGroups, el modelo soporta directamente la transferenciade
estado, pero sta se disea sobre un sistema interno de comunicaciones y la
transferenciaensnoladirigeJavaGroups,sinolaaplicacinmisma.Deestaforma,
ocurre lo mismo que con xAmp, Transis o Spread y, bajo ciertas circunstancias, el
modelodesincronavirtualnoserespeta.
La mayora de los sistemas expuestos s soporta con mayor o menor
flexibilidad la transferencia de estado. En este caso, se emplean dos mtodos
alternativos y solamente Totem soporta ambos simultneamente. El primer mtodo
es el almacenamiento de estados intermedios y mensajes de tal forma que sea
posible reconstruir el estado final de un objeto sin necesidad de acceder a otras
rplicas. Este planteamientosesigueenCORBAyenCactus,siendoatractivoalno
bloquearenningnmomentoningunadelasrplicasactivas.Sinembargo,requiere
tiempo de procesado continuo por parte de la aplicacin, donde cada rplica debe
almacenar peridicamente su estado y el sistema debe mantener una lista de los
mensajes procesados. Adems, puede resultar ms lenta la activacin de la nueva
rplica.
El mtodo alternativo es la transferencia de estado entre rplicas. Este
planteamiento es necesario en el caso del modelo de sincrona virtual extendida,
dondedistintasparticionesdebenacordarunestadocomn,quecadarplicaasume
entonces. Al emplear transferencia entre rplicas, es comn bloquear todo elgrupo
(Arjuna,Phoenix,Electra,CyberBus)yrealizarlatransferenciaenunsolopaso.
Soportar transferencias envariospasos,quepuederesultarimprescindibleen
el caso de rplicas complejas,esfuncionalenvariossistemas,principalmenteenla
versinoriginaldeMaestroyenelcomplejoTotem.Enelprimercasoessloposible
emplear una transferencia pull, donde el nuevo miembro elige a su coordinador,
aunqueadmiteflexibilidadenlaformadelbloqueo,puespermitebloquearmensajes
especficos. En el caso de Totem, la aplicacin puede seleccionar el mtodo de
bloqueo,bloqueandoatodaslasrplicas,alasrplicasquerealizanlatransferencia,
oinclusoaninguna.
Sensei se enfoca en el problema de la transferencia deestado,estudiandolas
diferentes posibilidades y ofreciendo unos protocolos con la mayor flexibilidad
posible.Estaflexibilidadincluyelaeleccindeprotocolospushopullqueafectanal
rendimientodelsistema,laposibilidaddeelegiralcoordinadordecadatransferencia
y el poder realizar transferencias concurrentes simultneamente, el soportar
transferencias en varios pasos e incluso interrumpirlas y continuarlas en caso de
cambios de vistas, el empleo de propiedades, o estado asociado al grupo como una
entidad,oelpoderbloquearelsistemaylosmensajesentrerplicas,etc.Definelos
protocolos a bajo nivel que permiten esta flexibilidad y se estudia su rendimiento
bajo diferentes condiciones, al ser muy distinto el entorno de una red localqueun
grupo comunicndose en Internet. Define tambin los protocolos a alto nivel,
especificndose una interfaz de aplicacin que soporta distintos grados de
complejidad, de tal forma que las aplicaciones que precisan una transferencia de
estado simple no deban soportar una interfaz compleja. Y estudia finalmente las
condicionesdelatransferenciadeestado,esencialparaentenderlasnecesidadesde
bloqueodelsistemaycmostasafectanalmodelodesincronavirtual.
Condicionesenlatransferenciadeestado 57
Captulo5-CONDICIONESENLA
TRANSFERENCIADEESTADO
El principal propsito de este captulo es estudiar la transferencia de una
formaterica,comprobandolascondicionesquedebenverificarseencadamomento
en respuesta a los distintos eventos que se dan en el grupo durante esa
transferencia.
El objetivo de la transferencia de estado es que todos losmiembrosdelgrupo
alcancen un estado consistente, cuando uno o ms miembros con estado no
inicializado se unen a un grupo ya consistente. El grupo inicial podra tener
miembros sin estado consistente slo si ya haba una transferencia en marcha
cuandoelnuevomiembrofueincluidoenelgrupo.
Esta definicin del problema excluye ya una solucin: que el futuro miembro
contacte primero a un miembro del grupo para recibir el estado y, tras recibirlo,se
una al grupo. Esta solucin requerira que el miembro contactado registrara los
cambiosproducidosensuestadodesdeelmomentoenquelotransfierehastaqueel
nuevomiembroseuneefectivamentealgrupo.Yesoscambiosdeberanentoncesser
transferidos al nuevo miembro, lo que supone de nuevo un problema de
transferenciadeestadotalcomosehaformulado.
Aunque la transferencia de estado puede contemplarse como una
comunicacinbidireccionalentredosconjuntosnovacosdemiembrosenelmismo
grupo, delimitaremos primero el problema a las comunicaciones unidireccionales
necesariasparainicializarelestadodelnuevomiembroconelestadocompartidopor
lasrplicasyainicializadas.Eldominiodelproblemaesungrupobajoelmodelode
sincrona virtual, donde algn nuevo miembro se une al grupo, lo que asume que
hay ya al menos un miembro con estado inicializado. La solucin debe emplear las
primitivas de comunicaciones de grupo soportadas por el modelo de sincrona
virtual.
Para entender este problema, consideraremos el ejemplo de un sistema
distribuido de ficheros, donde cada rplica mantiene una copia de parte de los
ficheros que el sistema sirve. Las rplicas siguen el modelo de sincrona virtual,
empleandomensajesfiablesconordentotal:cadarplicavelosmismosmensajesen
elmismoorden.Cuandounarplicaseunealgrupo,recibelosficherosdesdeotra,
enunoomsmensajes.Paralospropsitosdeesteejemplo,supondremosqueuna
tercera rplica enva, durante esa transferencia, un mensaje para modificar un
determinado fichero; este mensaje se interpreta como aadir en una determinada
posicin del fichero actual la porcin de texto que se adjunta. Es decir, no es un
mensajeidempotente:siseprocesadosveces,eltextoseaadedosveces.
La figura 5.1 muestra un hipottico escenario, donde una rplica enva el
mensajedeestadotrasrecibiryprocesarunmensajequemodificaeseestado.Este
mensaje contiene, por consiguiente, el estado final en que debera quedar la nueva
rplica.Elnuevomiembrorecibedosmensajes,eldeestadoyeldemodificacinde
estado, y no puede saber si el primero incluye ya en su estado las modificaciones
incluidas en el segundo. En este escenario, recibe primero el mensaje de
modificacindelficheroyloguardaparaprocesarlotrasrecibirelestado:terminar
consecuentemente en un estado inconsistente, pues incluir las modificaciones
sobreelestadoyamodificado.
fichero
f.modificado
Rplica A Rplica B
Nuevomiembro
Hacer
despus
Mensaje
deestado
Figura 5.1.Mensaje con estadoenviadotrasrecibir y procesar el
mensaje conla modificacin.
Estecasosesolucionaranoprocesandoelsegundomensaje,peroelescenario
dibujado en la figura 5.2 muestra el resultado de descartar ese mensaje bajo
condiciones opuestas. En este caso, el mensaje de estado es enviado antes de
procesarseelmensajedemodificacin,porloquelarplicaqueseunealgrupodebe
procesaresemensajeparaterminarenunestadoconsistente.Hayotrosescenarios
donde el mensaje no se guarda, pero en esos casos se puedenalcanzarigualmente
estadosinconsistentes.
La solucin ms sencilla sera bloquear el sistema completo durante la
transferencia, de tal forma que no se pudieran enviar mensajes que modificaran el
estado, pero el rendimiento del sistema disminuir dramticamente si el estado a
enviar es grande o se producen abundantes cambios de vistas. En el anterior
ejemplo, resulta evidente que sera suficiente con que la rplica que realiza la
transferencia almacenara todos los mensajes recibidos hasta enviar el estado; el
nuevomiembrotambinlosalmacenaraparaprocesarlostrasrecibirelestado,con
lo que ambos miembros terminaran en un estado consistente. El problema se
complicasielestadodebeserenviadoenvariosmensajesylarplicaqueloenvase
caeantesdecompletarlatransferencia.
Comosehadescritoenelcaptuloanterior,latransferenciadesdeotrarplica
no es el nico mecanismo posible para realizar la transferencia, pues el estado
puede reconstruirse a partir de archivos de estado, como es el caso de Cactus
[Schlichting93] o la especificacin de tolerancia a fallos de CORBA. Esta
aproximacin implica que las rplicas deben emplear continuamente tiempo de
proceso, en lugar de exclusivamente en los momentos en quelatransferenciadebe
ser realmente realizada. Pero adems, los archivos que guardan el estado deben
Figura 5.2.Mensaje con estadoenviado antesde recibir el
mensaje conla modificacin
fichero
f.modificado
Rplica A Rplica B
Nuevomiembro
Hacer
despus
Mensajede
estado
estar tambin replicados, lo que implica que a un nivel inferior existe todava una
transferenciadeestadoentrerplicas.
Las siguientes secciones estudian las condiciones que deben ser satisfechas
por los grupos y sus mensajes en las transferencias de estado desde una o ms
rplicas activas. Esnecesariogeneralmentebloquearlasrplicasinvolucradasenla
transferencia, excepto en los casos ms simples, pero el bloqueo y filtrado de los
mensajes dependen del tipo de orden empleado en los mensajes. Tambin se
consideran las transferencias en varios pasos, un requisito importante cuando el
estadodelgrupoessuficientementegrande.
5.1.Modeloydefiniciones
Este estudio de la transferencia de estado muestra que, incluso si no se
bloqueaningnmiembrodurantelatransferencia,esposiblereconstruirelestadoa
partir deunconjuntodemensajesyunmensajequecontieneunestadoalcanzado
tras haber procesado un subconjunto del primer conjunto de mensajes. Debe
notarse que el orden en que esos mensajes son recibidos depende de las
restriccionesdeordendelaaplicaciny,exceptocuandoseempleaordentotal,ese
orden de los mensajes no puede predecirse en absoluto. Aunque la anterior
conclusin puede resultar natural, formulamos el problema y demostramos una
solucin con una perspectiva formal. sto requiere introducir un modelo para el
sistema distribuido con componentes replicados, as como la correspondiente
notacinbsica.
Cada miembro tiene un estado, que contiene una parte comn a todas las
rplicas y una parte privada. La transferencia de estado slo considera esa parte
comn. Dos miembros tienen estados consistentes si, en ausencia de nuevos
mensajesenelgrupouotrainteraccinexterna,elprocesadodetodoslosmensajes
pendientes sitaaambosmiembrosenelmismoestadofinal.Elmensaje de estado
es el mensaje enviado a un miembro que se incorpora al grupo,desdeunmiembro
ya con estado al que llamamos coordinador de la transferencia o simplemente
coordinador. Ese mensajeincluyeelestadodelcoordinadorenunmomentodado,y
puedehabervariosmensajesdeestadosisteesenviadoenvariaspartes.
El modelo de sistema distribuido en que se realiza la transferencia de estado
consiste en componentes replicados en grupos y un GMS que sigue las siguientes
reglas:
Los grupos siguen el modelo de sincrona virtual. No se considera sincrona
virtualdbil[Friedman95].
Los cambios de estado en un miembro debido a cualquier interaccin externa
deben propagarse al resto de miembros en el grupo, usando las primitivas de
comunicacionesdegrupo.Sonposiblesdoscomportamientos:dinmicamenteno
uniforme, donde un miembro cambia su estado y lo comunica al grupo, y
comportamiento dinmicamente uniforme, donde realiza primero la
comunicacin al grupo y entonces cambia su estado. En el segundo caso,
consideramos que el miembro recibe su propio mensaje, que procesa al mismo
tiempoqueelrestodemiembrosenelgrupo.
Comportamiento determinista: dos miembros con el mismo estado que reciben
losmismosmensajes,enelordenespecificadoporlaaplicacin,evolucionarnal
mismoestadofinal.
Los miembros que se incorporan al grupo no realizan ninguna accin antes de
quelaprimeravistaseinstaleyelmiembroseaaceptadoenelgrupo.
LainteraccinentreelGMSylasrplicassemodeladelasiguienteforma:
Los miembros reciben secuencialmente los mensajes provenientes de otros
miembrosoelGMS:unmensajecadavez,sinrecibirelsiguienteantesdehaber
procesadoelprimero.Silosmiembrosalmacenaninternamentelosmensajes,el
GMSlosconsiderarprocesados.
El GMS instala una nueva vista slo cuando todos los mensajes en la vista
anterior han sido procesados. Es decir, el GMS est bloqueado en tanto que la
vistaquedainstalada.
ElGMSinformaalosmiembrosdelaanteriorcondicindebloqueo:unavezque
el GMS queda bloqueado, los mensajes enviados por un miembro son slo
recibidosporelgrupoenlasiguientevista.
Duranteelperiododebloqueo,unmiembrotodavapuedeenviarmensajes,pero
sonalmacenadosporelGMS,quelosenviaralosmiembrosenelgrupounavez
queseinstalalavista.Losmensajesenviadosporunmiembropuedenordenarse
fifo,perolosmensajesenviadospordiferentesmiembrosduranteesteperiodode
bloqueoseconsideranconcurrentes.
Lasiguientenotacinexpresamsformalmentelaanteriordiscusin:
Estado: S=s+s. El estado del miembro contiene una parte global (s) y una
parteprivada(s).Elproblemadelatransferenciadeestadosloseaplicaalaparte
global.
Miembros del grupo: G={g1, g2 gn} (n 1). El grupo incluye a todos los
miembros, con o sin estado. GS={g1, g2 gm} / (n m) representa la lista de
miembros inicializados, que comparten un estado comn, y puede ser vaca. Los
miembros no inicializados vienen dados por GU, que puede ser igualmente vaco.
Esta notacin asume quelosmiembrossonincluidosdirectamenteenelgrupoyla
transferenciadeestadosloesiniciadatraslainclusindelmiembroenelgrupo.
Sucesin deestados:siv={siv1, siv2 sivl}Cadamiembroitieneencadavista
v una sucesin de estados. Cuando la informacin de la vista no es necesaria, la
eliminamosdelanotacin:si={si1, si2 sil}.Enunsistemafuertementesncrono,es
decir, con sincrona virtual fuerte y mensajes dinmicamente uniformes con orden
total causal, todo miembro inicializado observa la misma secuencia de estados: sin=
sjn,i,jm.
Mensajes:
Mijeselconjuntoordenadodemensajesyaprocesadosporjperonopori,queha
sidoenviadoodebeserenviadoai,sijnocaeprimero.

=
i j
ij i
M M
: son los mensajes que deben ser procesados por i porque los
demsmiembrosenelgrupoloshanprocesadoya.
Mij = , j m: los miembros que se sumanalgruponorealizanningunaaccin
antesdeseraceptadosenelgrupo.
Si se disea un grupo para tomar acciones exclusivamente tras recibir un
mensaje, ningn miembro puede haber procesado algn mensaje que otros
miembros no hayan procesado cuando una nueva vista es instalada. Estos
miembrosreaccionanaeventosexternosenviandomensajesalgrupo,ytomando
laaccincorrespondienteslocuandoelmensajeesrecibido.Porlotanto:Mij=,
i,j. Esos mensajes son mensajes loopback: los mensajes dinmicamente
uniformesoprocesadosconordentotalsonmensajesloopback.
Mij = , i,j m siv1= sjv1 ,i,j m.: Si Mij es vaco para cualquier par de
miembros, todo miembro con estado tiene el mismo estado tras instalarse una
vista.
Mnp es el conjunto ordenado de mensajes que han sido ya enviados por algn
miembroenelgrupo,peroqueningnmiembrohaprocesadotodava.
Orden de mensajes: M M significa procesar ambos grupos de mensajes en el
ordenespecificadoporlaaplicacin,entantoM+MsignificaprocesarprimeroM
yluegoM.
Conjuntos de mensajes. M = M significa que ambosconjuntosdemensajesson
idnticos, incluyendo el orden de los mensajes. M M significa que ambos
conjuntos incluyen los mismos mensajes, pero el orden puede ser diferente,
dependiendodelasrestriccionesdelaaplicacin.
Subconjuntosdemensajes: M defineunsubconjuntodemensajesen M .
Mensaje de estado. ms / sO + ms = s: un miembro en su estado inicial que
recibe unmensajedeestadoadoptaelestadoincluidoenesemensaje.Sielestado
seenvaenvariaspartes,laanteriorreglaseespecificacomo:sO+(ms1ms2
msn)=s.Engeneral,msi
j
serefierealaporcinj-simadelestadosi,yM
j
eselgrupo
de mensajes en M que modifican la porcin j-sima; debe notarsequeesosmismos
mensajespodranmodificarigualmenteotrasporcionesdelestado,nonicamentela
porcin especificada, pero no puede haber otros mensajes que modifiquen esa
porcindada.
5.2.Requisitosparalatransferencia
Comenzamos imponiendo algunas restricciones que luegoeliminamos:nose
producencambiosdevistasdurantelatransferencia,elestadoseenvaenunnico
mensaje y no se envanmensajesenelgrupodurantelatransferencia.Finalmente,
todos los mensajes en el grupo, incluyendo el mensaje de estado, siguen el mismo
orden. Los siguientes requisitos obvian los mecanismos que deben implementarse
para detectarse cundo debe iniciarse una transferencia o cundo debe darse una
transferenciaporconcluida.
Suponemos tres miembros, uno de los cuales debe recibir el mensaje de
estado. Los miembros con estado, g1 y g2 pueden presentar un estado diferente,
pero deben ser consistentes y, consecuentemente, concluirn en el mismo estado
final tras procesar todos sus mensajes pendientes. Los mensajes pendientes son
aquellosenviadosenlavistaanteriorduranteelperiododebloqueo,ysondiferentes
paracadamiembro:
21 2 2 2 12 1 1 1
, : , : M M siendo M Mnp g M M siendo M Mnp g = =
Cualquiera de los miembros con estado puede ser el coordinador. Cada
miembro procesar un subconjunto de los mensajes pendientes y alcanzar un
estadointermedio,quepuedeserdiferenteenambosmiembros.Enesemomentoel
coordinador enviar el mensaje de estado, que contendr ese estado intermedio
alcanzado. A continuacin, procesar el resto de los mensajes. Dividiendo el
conjuntodemensajesaprocesarendossubconjuntos,esposibleescribir:
= +
= +
+ =
= +
= +
+ =
) (
:
:
) (
:
:
1
2 2
21
: 2
1
1 1
12
: 1
enviado estado
s M s
s M s
estado
M M M Mnp mensajes
g
enviado estado
s M s
s M s
estado
M M M Mnp mensajes
g
F D
C I
D C
F B
A I
B A
El miembro que recibe el estado debe procesar sus propios mensajes

pendientesyelmensajedeestadoparaalcanzarelmismoestadofinal:
( )
( )
( )
= +
= +
=
F O
F O
s ms M Mnp s
s ms M Mnp s
g de recibido
g de recibido
estado
M M M M M M Mnp M Mnp mensajes
g
2 3
1 3
2
1
12 32 21 31 32 31 3
3
:
:
:
:
:

Y, en general, para un nmero indefinido de miembros, los miembros con
estadoverificarn:
( ) [ ] 1
; ;
: /
F i i O B i O B i
F B i i A Ii B A i
i
s M Mnp ms s M ms s M s
s M s s M s M M M Mnp
m i g
= + + = + + = +
= + = + + =

Y los miembros que reciben el mensaje de estado deben cumplir, para
cualquiercoordinador:
( ) ( ) [ ] 2
: , /
F i ji i O i j O
ji i ji
i k
ik ji
i k
jk
k
jk j
j
s ms M M Mnp s ms M Mnp s
M M M M M M M M
m i m j g
= + = +
= = =
>

Juntandolasdosecuacionesanteriores,obtenemos:
( ) ( ) [ ] 3 :
i ji i O i i O
ms M M Mnp s M Mnp ms s m i + = + +
Esta es la condicin general que debe cumplirse en toda transferencia de
estado:debeserposiblereconstruirelestadoapartirdeunconjuntodemensajesy
un mensaje de estado cuyo estado asociado se ha alcanzado tras haber procesado
un subconjunto de aquel conjunto de mensajes. Debe tenerse en cuenta que el
orden en que esos mensajes y el mensaje de estado son recibidos depende de las
restriccionesdeordendelapropiaaplicaciny,salvoqueseempleeordentotal,ese
ordennopuedepredecirseenabsoluto.
Un ejemploesunaaplicacinreplicadaquemantieneunalistadeclientesy
cuya nicaoperacindeactualizacinserealizamedianteelmensajeaadir cliente
si no est en lalista.Elmensajedeestadoincluyelalistacompletadeclientes,que
constituye el estadodecadarplica.Esteejemploverificalaanteriorcondicin.Sin
embargo, si el grupo permitiera operaciones como eliminar cliente, la anterior
condicinnosecumplirayaentodosloscasos.Porejemplo,comosemuestraenla
figura 5.3, pueden enviarse dos mensajes en el grupo, uno aadiendo un cliente y
otro eliminando ese mismo cliente. Un miembro podraprocesarelprimermensaje,
enviandoacontinuacinelmensajedeestadoqueincluira,porlotanto,esecliente.
A continuacin procesara el segundo mensaje y terminara en un estado final que
no incluye aquel cliente. El nuevo miembro podra procesar primero los dos
mensajes,aadiendoyeliminadoelcliente,yrecibiraacontinuacinelmensajede
estado.Terminaraasenunestadoinconsistente,puessuestadofinalcontendraal
clientesupuestamenteeliminado.
Eliminando ahora la primera restriccin y permitiendo el envo de nuevos
mensajesdurantelatransferenciadeestado,seobtieneunacondicinsimilar:
( ) ( ) [ ] 4 : M ms M M Mnp s M M Mnp ms s m i
i ji i O i i O
+ = + +
Esta ecuacin puede simplificarse en [5], que puede entenderse como [4]
cuando el periodo de bloqueo previo al cambio de vista es tan corto que ningn
miembroprocesaoenvaningnmensaje:
( ) [ ] 5 : M ms s M ms s m i M M M Mnp M
i O i O ji i
+ = + +
DebedestacarsequeelsubconjuntoMdemensajesenlaparteizquierdade
esta frmula se compone de aquellos mensajes en M que todava no se han
procesado en el momento en queelestadoseenva,peroqueelconjuntocompleto
de mensajes, as como el mensaje de estado, deben ser procesados en la parte
derecha de la frmula. Adems, el mensaje de estado debe serprocesadoentredos
mensajes cualesquiera en ese conjunto, sin que el orden afecte al estado final
alcanzado. Una posibilidad de verificar esta condicin es incluir en el mensaje de
estadoinformacinsobrelosmensajesquesehanprocesadoparaalcanzarelestado
dado; por ejemplo, si los mensajes estn numerados secuencialmente, bastara con
incluirelltimonmerodesecuencia.
Un caso interesante es aqul enqueelestadoseenvainmediatamentetras
recibir la nueva vista, sin mensajes intermedios. El otro caso posible, enviarlo
cuandosehanprocesadotodoslosmensajespendientes,noresultataninteresante
pordosrazones:primero,porqueesdifcildeimplementarenunsistemaasncrono,
al ser difcil detectar que no hay ms mensajes pendientes y, segundo, porque
debera inhibirse el envo de nuevos mensajes mientras se transfiere el estado.
Cuandoelestadosetransfiereinmediatamentetrasrecibirlanotificacindecambio
devista:
( ) [ ]
( ) [ ] 7 :
6 :

M ms s M ms s m i i M si
M M ms s M ms s m i
M M M M M
M M Mnp M M
i O i O i
ji i O i O
ji ji
i
+ = + + =
+ = + +
Esta ltima simplificacin [7] es vlida para grupos que envan

exclusivamente mensajes loopback. Implica que no debe haber ninguna diferencia
entre procesar primero el mensaje de estado y a continuacin un conjunto de
mensajes, o procesar el conjunto entero de mensajes, con el mensaje de estado
incluidoentredoscualesquieradeesosmensajes.Unejemplodeaplicacindegrupo
que cumple [7] es un contador donde todo mensaje tiene un significado relativo,
como incrementar contador o decrementar contador, y donde el mensaje de estado
Figura5.3.Ejemplo de escenario detransferenciacon
inconsistencia finaldeestados.
Rplica A Rplica B
Nuevomiembro
mensajede
estado
se entiende tambin como un incremento relativo: incrementar contador en la
cantidad especificada por el nmero dado en el mensaje de estado. Incluso este
ejemplo sobresimplificado no verifica [5], porque el mensaje de estado podra ser
enviado tras procesar alguno de los mensajes incrementar contador en la vista
actual, mensajes que sern procesados igualmente por el nuevo miembro,
terminandoenestados(contadores)finalesdiferentes.
Lascondicionespreviassondifcilesdeverificarengruposgenricos.Incluso
lacondicinmssimple[7]carecedeunasolucingeneral,porqueningntipode
ordenpuedeconseguirqueelnuevomiembrorecibaprimeroelmensajedeestadoy
luegolosmensajesrestantes,loqueresolveradirectamentelaecuacin.
Proponemoslasiguientesolucinparavalidarlatransferenciadeestadopara
cualquiertipodemensajesdegrupoymensajesdeestado:elmensajedeestadose
enva inmediatamente tras el cambio de vista y el nuevo miembro encola todo
mensaje hasta recibir y procesar el mensaje de estado. Una vez que lo procesa, los
mensajes encolados se desbloquean y procesan en el orden de entrada.Sielgrupo
emplea mensajes no-loopback, es tambin necesariodescartarMji,losmensajesque
yahabansidoprocesadosporelcoordinadorenlavistaprevia.Enesecaso:
( ) ( ) M ms s M M ms s M M ms s
i O ji i O ji i O
+ + = + + = +
Con lo que se cumple la condicin [6]. Como slo deben descartarse los
mensajesenviadosporelcoordinadorprevios almensajedeestado(losenviadosen
la vista previa), esta solucin implica que cuando el grupo contiene mensajes no-
loopback,elordendemensajesenelgrupodebeser,almenos,fifo.Ycomoungrupo
puede usar tanto mensajes loopback como no-loopback, es la misma aplicacin
quiendebedecidirlosmensajesadescartar:aquellosqueseanno-loopback.
Las ecuaciones previas, obtenidas para todo tipo de grupos, no cambian si
haymsdeunnuevomiembro,ynohaydiferenciasihayuncoordinadorparacada
nuevo miembro o un nico coordinador para todos los miembros nuevos, y la
transferencia se realiza entonces secuencial o concurrentemente. Si se realiza
secuencialmente, la solucin basada en el envo del estado inmediatamente tras el
cambiodevistarequiereahoraqueelcoordinadornoproceseningnmensajehasta
quetodaslastransferenciassecompleten.
5.2.1.Cambiosdevistas
Si se produce algn cambio de vista antes de que el coordinador enve el
mensaje de estado, la condicin a verificarse en un grupo genrico sigue siendo la
misma que cuando no hay cambios de vistas [5]. Para demostrarlo, supondremos
quetrasenviarseelmensajedeestado,ningnmiembroenvamensajesadicionales
y no se instalan nuevas vistas en el grupo. El nuevo miembro deber procesar un
conjunto de mensajes M. Primero procesar un subconjunto de esos mensajes, a
continuacinelmensajedeestadoy,finalmente,losmensajesrestantes.
F B A O B A
s M ms M s estado M M M mensajes = + + + + = : :
Pero, si el grupo verifica [5], el orden en que el mensaje de estado es
procesadonoafectaalestadofinal:
F O B A O B A O
s M ms s M M ms s M ms M s = + + = + + + = + + +
Y el mensaje de estado incluye un estado obtenido tras haber procesadoun
subconjunto de los mensajes en M, exactamente con la solucin en [5]. Por
consiguiente, no se precisan nuevas restricciones en el caso en que se produzcan
cambios de vistas antes de que el mensaje de estado se enve, incluso si el
coordinadorcaeyotromiembroconestadoseconvierteenelnuevocoordinador.
Nuestra propuesta para resolver la transferencia de estado en grupos
genricos que no cumplen [5] implica que, debido al bloqueo de mensajes, los
miembrosinvolucradosenlatransferenciapuedenparecermiembroslentosrespecto
alosdemsmiembrosenelgrupo.Yloqueesmsimportante,cuandoseproduce
uncambiodevistaantesdequelatransferenciafinalice,unapropiedaddelmodelo
de sincrona virtualpuedeestarsiendoviolada.Estemodeloestablecequetodopar
de procesos que sean miembros de dos vistas consecutivas deben recibir el mismo
conjunto de mensajes en el periodo comprendido entre ambas vistas. Cuando la
vistacambia,tantoelcoordinadordelatransferenciacomoelnuevomiembroquela
recibe tienen mensajes encolados que no pueden procesar porque la transferencia
an no ha finalizado. De hecho, los mensajes han sido recibidos, por lo que la
propiedad se respeta, pero las aplicaciones en grupo que usen esta aproximacin
debentenerestaposibilidadencuenta.Elsistemapuedemodelarsededosformas:
El coordinador y el nuevo miembro son considerados como miembros excluidos
temporalmente de la vista. Continan bloqueando los mensajes, que slo son
procesados cuando la transferencia queda completada. Cuando los mensajes
sean procesados, procedern probablemente de dos o ms vistas pero, incluso
as,seprocesarnenelordencorrecto.
El nuevo miembro no se considera incluido en la vista en tanto no se le
transfieraelestado.Enestecaso,elcoordinadorcancelaralatransferenciasise
instala una nueva vista, procesando los mensajes encolados y reiniciando la
transferencia en la nueva vista. El nuevo miembro debe descartar los mensajes
encoladossirecibeunanuevavistaantesderecibirelmensajedeestado.Como
debido a problemas de sincronizacin el coordinador podra haber enviado ese
mensaje de estado antes de percibir que la vista estaba bloqueada, el nuevo
miembro debe ser capaz de descartar este mensaje, que recibir en la siguiente
vista.Unaposibilidadesincluirlaidentidaddelavistaenelmensajedeestado.
Ambas soluciones excluyen, cuanto menos, al nuevo miembro como
perteneciente al grupo. Puede verse entonces como una solucin equivalente a
aquella en la que el futuro miembro del grupo solicita el estado a un miembro
pertenecientealgrupoy,cuandolorecibe,seincorporaaesegrupo.
Adems, debe considerarse que un miembro que ha encolado los mensajes
puede caerse mientras los procesa. Volviendo de nuevo al modelo de sincrona
virtual, si un miembro es incluido en una nueva vista debe haber procesado todos
los mensajes de laanteriorvista.Sinembargo,siunmiembrorecibelanotificacin
de nueva vista y decide entonces procesar los mensajes encolados, puede en ese
momento caerse, sin haber procesado todos los mensajes que le correspondan, y
violandoaselmodelodesincronavirtual,afectandoalasaplicacionesqueconfan
en este modelo para su correcto funcionamiento. La nica solucin para este
problemaimplicaquelosmiembrosdebenrecibirlanotificacindelbloqueodevista;
en este momento procesarnlosmensajespendientesy,sisecayeranduranteesta
fase, no apareceran como miembrosdelanuevavista.Debenotarsequeelmodelo
de sincrona virtual no define el evento de vista bloqueada, y no es necesario si la
transferenciadeestadoseimplementadirectamenteenelmismomodelo;esteevento
se produce en el grupo cuando los miembros reciben la peticin de inclusin de
algn nuevo miembro o han detectado la cada de algn antiguo miembro y
comienzanapactarelcontenidodelanuevavista.
Siseinstalaunanuevavistayelcoordinadordeunatransferenciaencurso
cae, otro de los miembros con estado debe asumir su papel y completar su
trasferencia. Sin embargo,nuestrapropuesta,comoocurraconlassimplificaciones
[6,7],asumequeelmensajedeestadoseenvaantesdequeelcoordinadorprocese
ningn mensaje de la nueva vista, es decir, de la vista en que se inicia la
transferencia. Como resultado, el nuevo miembro espera un mensaje con el estado
del coordinador tras la instalacin de la vista. Si otro miembro asume el papel del
antiguo coordinador, an debe enviar aquel estado, para lo que hay varias
posibilidades:
Los miembros con estado guardan su estado tras cada cambio de vista. Como
dos miembros podran incorporarse al grupo en dos vistas consecutivas, esta
solucin implica que los miembros deberan ser capaces de almacenar varios
estados.
O bien esos miembros congelan sus estados, simplemente no procesando
ninguno de losnuevosmensajeshastaquetodatransferenciafinalice:todoslos
miembrosdelgrupoquedanbloqueados.
O bien cada miembro con estado se comporta como coordinador y enva su
estadoalosnuevosmiembroscuandoseinstalaunavista.
Una ltima y favorable solucin es que el nuevo miembro descarte todos los
mensajes encolados durante la vista previa, tal como si el miembro se
incorporaraalgrupoenlaltimavistainstalada.Estasolucineslamismaque
ya usamospreviamentealmodelarelsistemayeslaqueescogemosennuestra
aproximacin.
Finalmente,debeconsiderarseelcasoenqueseinstalalavistaantesdequeel
coordinadorenvesuestado,yesecoordinadordebatransferirsuestadoigualmente
a nuevos miembros incorporados en la ltima vista. Nuestra aproximacin implica
que todos los nuevos miembros pasan a considerarse como miembros incorporados
enlaltimavista,porloqueestecasonoaadeningunadificultad.
5.2.2.Transferenciasdeestadosenvariospasos
Estados grandes pueden requerir dividir el mensaje de estado en varios
mensajes. El nuevo miembro debe entonces recibir cada uno de los mensajes, que
pueden ser enviados por diferentes coordinadores.Bajoestascondiciones,elnuevo
miembrodebesatisfacer:
( ) [ ] 8 : /
2 1
F
p
U B A j O j
s ms ms ms M Mnp s m j g = +
Es decir, el estado final se obtiene a partir de los mensajes de estado y un
conjuntodemensajespendientes;peroesosmensajesdeestadopuedenprovenirde
diferentesmiembroscondistintosestadosyquehayanyaprocesadoalgunosotodos
los mensajes que el nuevo miembro debe procesar. Esta condicin general es
evidentemente difcil de satisfacer de forma genrica. Un ejemplo de aplicacin que
la satisface en un grupo que almacena todos los mensajes enviados en el grupo, e
inicializaalosnuevosmiembrosenvindolesesosmensajes;pero,enestecaso,cada
mensajedeestadoserefierealamismainstanciadeestado,estoes:sA=sB==sU..
Incluso cuando hay un nico coordinador, la condicin anterior no se
simplifica, pues los diferentes mensajes de estado podran referirse a distintas
instanciasdelestado,yaqueelcoordinadorpuedeevolucionaralprocesarmensajes
entrantes.Sitodomensajedeestadoserefiriesealmismoestado,lasolucinssera
ms fcil. Como vimos en la transferencia normal, esdifcilesperaraprocesartodo
mensajependiente,ynosenfocaremosenelcasoenqueelestadoseenvasinhaber
procesadoningnmensajedelanuevavista.Enestecaso,esimportantenotarque
nohayningunadiferenciaentretenerunnicocoordinadorovariossilosmensajes
son del tipo loopback, pues entonces todos los coordinadores presentan el mismo
estado cuando las vistas son instaladas. El coordinador comienza en un estado
inicialyevolucionaralestadofinalalprocesarlosmensajespendientes(MnpyMi);
el miembro nuevo procesar igualmente sus mensajes pendientes (Mnp y Mj) as
como los mensajes de estado para alcanzar el mismo estado final. Si hay un nico
coordinador:
( )
( ) ( )
( )
( ) ( ) ( ) [ ] 9
: / :
: / :
1 1
1
1
1
p
Ii Ii ji i O i
p
Ii Ii O
ji i ji
i k
ik ji
i k
jk
k
jk j
F
p
Ii Ii j O j
F i
p
Ii Ii O
p
Ii Ii Ii
Ii Ii O
F i Ii
i
ms ms M M Mnp s M Mnp ms ms s
M M M M M M M M
s ms ms M Mnp s m j g miembro nuevo
s M Mnp ms ms s
ms ms ms
s ms s
s M Mnp s
m i g r coordinado
+ = + +
= = =
= + >
= + +
=
= +
= +

Si hay varios coordinadores transfiriendo el estado, Mi debe ser el conjunto
vacoparatodoslosmiembros:
( )
( )
( ) ( ) [ ] 10
: / :
: / :
1 1
1
1
1
p
I I O
p
I I O
F
p
I I O j
F
p
I I O
p
I I I
Ii I O
F I
i
ms ms Mnp s Mnp ms ms s
s ms ms Mnp s m j g miembro nuevo
s Mnp ms ms s
ms ms ms
s ms s
s Mnp s
m i g res coordinado
+ = + +
= + >
= + +
=
= +
= +

Estas dos ecuaciones son simples complicaciones de las frmulas obtenidas
para transferencias en un solo mensaje ([6] y [7]): el orden en que todo par de
mensajes, incluyendo los mensajes de estado, es procesado no puede afectar al
estadofinal.
Existeuncasoespecialcuandoelestadoylosmensajessedefinendetalforma
quecadamensajeslomodificaunadelasporcionesdelestado.Sihaypporciones,
ylesunaporcinespecifica,podemosobtenerapartirde[8]paracadaporcin:
( ) [ ]
( ) [ ] 11
2 1
l
F
l
i
l
j
l l
O
j
X
l
F
l
p
U B A j O
s ms M Mnp s
ms l j
s ms ms ms M Mnp s
= +
=
= +

[11] debe verificarse en cada porcin l, cuando el estado se recibe de un
coordinador cualquiera i, que podra ser diferente para cada porcin. Este
coordinador habr procesado una parte de los mensajes entrantes antes de haber
enviadosumensajedeestado:
( )
( )
( )
[ ] 12 ) (
) ( :
; :
:
: /
l
F
l
i
l l
i
l
O
l
i
l
i
l
O
l
F
l
i
l l
i
F i i
F B i i A Ii F i Ii
i B B A i
i
s M Mnp ms s
s ms s
s M Mnp s porcion
s M Mnp s
s M s s M s s M Mnp s estado
M Mnp M M M M Mnp mensajes
m i g
= + +
)
`
= +
= +
= +
)
`
= + = + = +
= + =

Comparando[11]y[12],obtenemosunaecuacinsimilara[3],quedebeser
satisfecha para cada porcin del estado, porciones que pueden ser transferidas
posiblementeporcoordinadoresdiferentes:
[ ] 13 ) ( ) (
l
F
l
i
l
ji
l
i
l
np
l
O
l
i
l
np
l
i
l
O
s ms M M M s M M ms s = + = + +
Sinosebloqueanlosmensajesmientrasserealizalatransferencia,debenser
incluidosenlaanteriorecuacin:
[ ] 14 ) ( ) (
l
F
l
i
l l
ji
l
i
l
np
l
O
l l
i
l
np
l
i
l
O
s ms M M M M s M M M ms s = + = + +
Para obtener una solucin genrica para todo tipo de grupos, extendemos la
solucinpropuestaparatransferenciasenunsolopaso.Losmensajesdebenquedar
ahora bloqueados en el nuevo miembro hasta que el ltimo mensaje de estado se
reciba,yeslaaplicacinlaquedefineculeselltimomensajedeestado.Sinohay
mensajes loopback, debedescartarsecadamensajeprovenientedelcoordinadorque
sea previo al ltimo mensaje de estado, por lo que se requiere cuanto menos
ordenacin fifo. Esta solucin implica que slo se emplear un miembro como
coordinador para una determinada transferencia. Sin embargo, ya que el
coordinador no puede procesar ningn mensaje en tanto la transferencia se
complete,tienesentidousarunsolocoordinadorynobloquearvariosmiembrosala
vez.
5.2.3.Cambiosdevistasentransferenciasenvariospasos
Cuando puede descomponerse el estado de un grupo en varias partes y los
mensajes actualizan exclusivamente una de esas partes, el problema de la
transferencia de estado puede descomponerse en n transferencias de estado en un
solo paso, donde cada transferencia se corresponde a cada una de las partes del
estado.Enestecaso,loscambiosdevistasintroducenlamismacomplejidadqueya
hemos observado en transferencias en un solo paso. En las aplicaciones en grupos
que satisfacen [8], esta condicin no se torna ms complicada, aunque los
miembros con estado deben ahora considerar el caso en que el coordinador o
coordinadorescaenantesdecompletarlatransferencia.
Lasolucinquepresentamosenelpuntoprevio,basadaenelenvodelestado
delcoordinadorantesdeprocesarningnmensajedelanuevavista,puedeemplear
igualmentelasestrategiasquesealamosduranteladiscusindetransferenciasen
un solo paso. Refirindonos a la solucin que directamente escogimos, donde el
nuevo miembro debe descartar los mensajes en cada cambio devista,debenotarse
que ahora debe descartarse igualmente los mensajes de estado previos, lo que la
convierte en unasolucincara:elestadosedivideenvariaspartesparaacelerarla
transferencia, pero debe reiniciarse cada vez que el coordinador se caiga. Incluso
suponiendo poco usuales las repetidas cadas de los sucesivos coordinadores, un
protocolo bidireccional entre el nuevo miembro y su coordinador acelerara la
transferencia, pues el nuevo miembro podra enviar al nuevo coordinador
informacinsobreelestadodesutransferencia.
5.3.Algoritmodetransferenciadeestado
Los anteriores puntos han mostrado que slo los sistemas ms sencillos
pueden realizar transferencias de estado bsicas sin realizar ningn procesamiento
adicional, en especial sin bloquear mensajes. El algoritmo que proponemos para
resolver la transferencia de estado de forma genrica se resume en los siguientes
puntos:
Elmensajedeestadodebeenviarseinmediatamentetraselcambiodevista,yel
nuevo miembro debe bloquear todo mensaje entrante en tanto no reciba y
proceseelmensajedeestado.
Tras procesar el mensaje de estado, los mensajes bloqueados se desencolan y
procesan en el orden de entrada. Si el grupo emplea mensajes no-loopback,
deben descartarse los mensajes que fueron procesados por el coordinador en la
vistaanterior.Enestecaso,elgrupodebedefiniralmenosordenfifo.
Noseconsideraalnuevomiembrocomopertenecientealgrupomientrasnosele
transfieraelestado.Cuandoseinstalaunanuevavista,elcoordinadorconcluye
cualquier transferencia en marcha y procesa los mensajes encolados. El nuevo
miembro descarta, en este caso, esos mensajes y esperar a que se inicie una
nuevatransferenciaenlasiguientevista.Elmensajedeestadodeberaincluirla
identidaddevistaparaquepuedadescartarsesiesrecibidoenlasiguientevista.
Siseenvaelmensajedeestadoenvariasporciones,losmensajesdebenquedar
bloqueados en el nuevo miembro hasta que se reciba el ltimo mensaje de
estado,siendolaaplicacinlaquedecideculesesteltimomensajedeestado.
Sinohaymensajesno-loopback,debedescartarsetodomensajedelcoordinador
previo al ltimo mensaje de estado, lo que implica la necesidad de orden fifo,
cuantomenos.
Si se enva el estado en varios pasos y el coordinador se cae, la solucin ms
sencilla es que el nuevo miembro descarte los mensajes de estado recibidos. El
problema de rendimiento asociado a esta solucin puede evitarse emplendose
protocolos bidireccionales, donde el nuevo estado enva al nuevo coordinador el
estadodelatransferencia.Estasolucinnoresultagenrica,cadagrupodeber
definir esos protocolos, siempre y cuando puedan permitir la continuacin de
transferenciasfallidas.
5.4.Conclusiones
Este captulo ha enfocado el problema de la transferencia cuando sta se
producebajocondicionesquemodificanelestadoquesetransfiere.Sehandescrito
las condiciones que deben verificar, tanto el grupo y sus miembros, como los
mensajes definidos en ese grupo para que la transferencia pueda realizarse sin
bloqueo de los miembros o los mensajes, observndose que slo los grupos ms
simplesverificanesaspropiedades.
Sehadescritodeestamaneraunalgoritmogenricoquepuedeimplementarse
en cualquier aplicacin para realizar una transferencia correcta en todos los casos.
Este algoritmo precisa de un bloqueo de mensajes, y el impacto de este bloqueo
sobreelmodelodesincronavirtualsehadetalladoigualmente.
Al hacer el anlisis de este impacto, hemos demostrado que es preciso queel
GMS haga pblico el evento de bloqueo de vista; aunque este evento est
generalmente disponible en los sistemas de comunicaciones fiables de grupo, el
modelodesincronavirtualnoloconsideraunapropiedaddelGMS.Y,enefecto,si
el GMS implementa directamente los protocolos de transferencia de estado, no es
precisoquetaleventoseapblico.
El siguiente captulo estudia los protocolos de bajo nivel que deben utilizarse
entre los miembros del grupo durante la transferencia, con el objetivo de comparar
lasdistintasposibilidadesdeimplementacin,ycomparandoigualmenteelefectode
implementaresosprotocolosenelmismoGMSocomounnivelporencimadeaqul.
Protocolosdetransferenciadebajonivel 75
Captulo6-PROTOCOLOSDE
TRANSFERENCIADEBAJONIVEL
Elcaptuloanteriorestudilascondicionesquedebenverificarsepararealizar
la transferencia de estado hacia miembros nuevos que se incorporan a un grupo,y
desarroll un algoritmo que validaba esa transferencia de forma genrica. Este
algoritmo se ha especificado de forma abstracta, y esta seccin define unos
protocolosdebajonivelsobrelosqueimplementarelalgoritmo.Enparticular,estos
protocolos son bidireccionales, permiten el intercambio de informacin entre el
coordinador de la transferencia y el nuevo miembro, lo que permite mejorar el
rendimiento del algoritmo en el peor caso: transferencias en varios pasos con
frecuentescadasdelossucesivoscoordinadores.
6.1.Requisitosdelosprotocolos
La transferencia de estado tiene varios problemas que resolver: consensuar
cul es el estado a transferir, quin debe por lo tanto recibirlo y quin inicia la
transferencia.Acontinuacin,habrquedeterminarcmoefectuarlatransferencia,
involucrando a todo el grupo o no, cmo y quin inicialatransferenciaosistase
realizaenunsolopasooenvarios.
Losprotocolosdebencumplirunaseriederequisitos:
Minimizarelanchodebandarequeridoparaefectuarlatransferencia.
Facilitar el envo del estado en varias fases, para facilitar a la aplicacin el
tratamientodeestadosgrandes.
Cubrir,tantolainicializacindemiembrosnuevosenelgrupo,comolauninde
particionesdelmismogrupo.
Eleccin del coordinador: la aplicacin puede decidir cmo determinar el
coordinadorparalainicializacindeunmiembronuevo;usarcualquiermiembro
con estado, favorecer el empleo de determinados miembros mediante el empleo
de pesos o realizar balanza de carga entre los miembros con estado. Tambin
permite delegarse esta decisin a la aplicacin, que podr de esta manera
seleccionarelcoordinadorapoyndoseeninformacinadicional,comopuedaser
laproximidadfsicademiembrosolabalanzadecargatotal.
Limitar la disponibilidad del grupo durante la transferencia: puede ser necesario
inhibir el envo de mensajes en el grupo, lo que supone que el grupo pierde
temporalmente su disponibilidad, al no poder responder a ninguna peticin de
servicio. Enelpolocontrario,puedeconsiderarsequelatransferenciadeestado
esmuycortaoquelosmensajespuedenrecibirsesincomplicarlatransferencia
de estado y, en ese caso, no se inhibe ningn mensaje durante estas
transferencias, evitando que el grupo pierda temporalmente su disponibilidad
comoservidor.Ungradointermedioseobtienecuandolatransferenciadeestado
seconsideraparcialmente seguraysepermiteelenvodelosmensajesdefinidos
como seguros; la aplicacin debe entonces diferenciar entremensajessegurosy
noseguros.Enestecaso,sepuedetambindiferenciarentrelatransferenciade
estado y la unin de particiones, definindose as distintos grados de seguridad
paraambosescenarios.
Grupos de varios niveles. Si un grupo distingue entre funcionalidad cliente y
servidor, la transferencia slo involucrar a los servidores. De la misma forma,
enlosgruposquepresentanreplicacinpasiva,enunoovariosniveles,tambin
debe realizarseunatransferenciaantedeterminadoseventosdependientesdela
aplicacin; un ejemplo es la activacin de un miembro en backup como
consecuenciadelacadadeunmiembroactivo,quedeberprimeroalcanzarun
estado consistente al resto de miembros activos mediante una transferencia de
estado voluntaria. Sin embargo, un miembro no activo se considera no
perteneciente al grupo, pues no interviene en los mensajes, su actualizacin es
dependientedelaaplicacinynoloconsideramoscomounapartadoespecialen
latransferenciadeestado.
Propiedades de los miembros. El problema de la transferencia de estado se
centra en la replicacin de un estado sobre un conjunto de rplicas de un
determinado objeto. Si la distribucin de rplicas no es uniforme y puede
considerarsequecadamiembroposeeunconjuntodepropiedadesquedebenser
conocidas por todos los miembros, estas propiedades no formarn parte del
estado ni delproblemadelatransferenciadeestado.Latransferenciadeestado
es un problema lgicamente mayor que la transferencia de propiedades. Ejem-
plosdepropiedadessonelpesoasociadoacadamiembroosulocalizacinfsica,
que puede servir a la aplicacin para seleccionar como coordinador al miembro
mscercano.
Inicializacin del grupo. El primer miembro que crea un grupo, crea un estado
inicialyempezaradarunservicio,transfiriendosuestadosinuevosmiembros
se incluyen en el grupo. Sin embargo, por problemas de particin de la red, un
miembro puede considerarse creador de un grupo al no poder comunicarse con
el resto de los miembros, y desarrollar un estado incompatible. Para soslayar
esta situacin, la aplicacin debe comunicar al servicio de transferencia de
estado cundo un miembro o conjunto de miembros sin estado pasan a
considerarsecomomiembrosconestado,concompletafuncionalidad.
Latransferenciadeestadoestenunnivelintermedioentrelaaplicacinyel
GMS. De hecho, gran parte de la funcionalidad requerida en la transferencia de
estado puede trasladarse al GMS para lograr un mejor rendimiento. Los protocolos
de transferencia han sido desarrollados para los dos casos posibles, con o sin el
soportedelGMS,loquepermitirestudiarlasventajasodesventajasdeextenderel
GMS con una funcionalidad ajena a su servicio: en su definicin, las vistas que se
envanalgrupoincluyennicamenteunalistaordenadadelosmiembrosdelgrupo
yningunainformacinadicionalsobreelestado.
Enlosgruposdeparticinprimariaexistendosformasposiblesderealizarla
transferencia de estado: transferencia push, donde los miembros con estado
coordinan la transferencia hacia el miembro omiembrossinestado,ytransferencia
pull,dondelosmiembrossinestadosolicitanlatransferenciadeestado.
6.2.Transferenciapush
Elalgoritmodetransferenciapushprecisaquecadamiembroconozcalalista
de miembros con estado y los miembros que stos estn coordinando. La
transferenciaserealizadelasiguientemanera,comosevisualizaenlafigura6.1:
Seleccin de un coordinadorparacadamiembrosinestado,siguiendolaspautas
definidasporlaaplicacin:usandopesos,balanzadecarga,etcEstaseleccin
es determinista,cadamiembrodelgrupodecideelcoordinadorparacadanuevo
miembro sin realizar comunicaciones internas, pero todos seleccionan a los
mismoscoordinadores.
El coordinador enva al nuevo miembro la lista de miembros con estado y los
miembros que coordinan, en un mensaje al que denominamos mensaje p,
mensaje de protocolo. Si se han definido propiedades, este mensaje incluye las
de los miembros con estado. En cuanto lo recibe, el nuevo miembro pasa a
conocerelestadodetransferenciasenelgrupo:qumiembrostienenestadoya
qumiembrosestncoordinando.
Si el nuevo miembro ha definido alguna propiedad, las enva al coordinador en
un mensaje de coordinacin llamado mensaje c. Se denomina mensaje de
coordinacin porque permite al nuevo miembro enviar informacin a su
coordinador; por ejemplo, sobre antiguas transferencias frustradas, como
explicamosmsadelante.
El coordinador transfiere el estado en uno o varios mensajes de estado (state
messages),denominadosmensajess.
Al finalizar la transferencia, el coordinador enva un mensaje multipunto final
(end message), denominado mensaje e, con el quelosdemsmiembrospasana
considerar al nuevo miembro como miembro con estado. Este mensaje contiene
laspropiedadesdelnuevomiembro.
Si un coordinador se cae, los miembros sin estado a los que coordina se
distribuyen entre los dems miembros con estado; por esta razn, cada miembro
debeguardarlalistademiembrosdecadacoordinador,ylaeleccindelcoordinador
debe ser determinista, pues no existe comunicacin entre los miembrosconestado
sobreesaeleccin.Enparticular,sisecaeduranteunatransferencia,elmiembroal
que coordinaba puede seleccionardirectamenteunnuevocoordinador,siyarecibi
delanteriorelmensajep.Enestecaso,puedeenviarleautomticamenteunmensaje
c de coordinacin de la transferencia, acelerando el protocolo. En la figura se
muestra que este mensaje c sera concurrente con el mensaje p recibido del
coordinador,puessteltimonopuedesabersielnuevomiembrorecibielmensaje
pensuanteriortransferencia,porloquedebeconsecuentementeenviarlo.
Figura 6.1.Protocolo de transferencia push.
p
s
p
c s
e
c
Mensajes
(p): transferirinformacindelprotocolo
(s): transferirestado
(c): coordinarestado
(e): vistadetransferencia
Nueva
vista
El contenido del mensaje c de coordinacin, no se define a este nivel del
protocolo, de la misma forma que no se definen los mensajes s de estado; ambas
definiciones deben realizarse a un nivel superior de este protocolo, tal como se
detallaenelsiguientecaptulo,aldefinirlainterfazdelaaplicacin.
Debenotarsequelaspropiedadesnosonestticasy,cuandounmiembrolas
modifica, debe enviar un mensaje a los dems miembros. Durante la transferencia,
el nuevo miembro no puede modificar sus propiedades, debe esperar a que el
coordinador enve el mensaje e. Sin embargo, si se produce un cambio de vista, el
protocolo permite al nuevo miembro enviar sus propiedades actualizadas al
coordinadorenelmensajec.
Esteprotocolonoincluyeningunarestriccindeconcurrencia,permitiendola
transferencia simultnea de estado a varios miembros. En particular, si dos o ms
miembros son asignados al mismo coordinador, este ltimo puede inhibir la
concurrencia al ser incapaz de manejar varias transferencias al mismotiempo;esta
limitacindeberincluirseenalgnnivelporencimadeesteprotocolo.
6.3.Transferenciapull
Con transferencia pull, visualizada en la figura 6.2, cada miembro slo debe
conocerlalistadelosmiembrosconestado,loquesimplificaelalgoritmoempleado:
p
e
r
s
r
s
Figura 6.2.Protocolo de transferencia pull.
Mensajes
(r): solicitarestado
(e): vistadetransferencia
Nueva
vista
Un miembro con estado es seleccionado determinsticamente para enviar en un
mensaje multipunto p la lista de los miembros con estado, as como sus
propiedades. Este miembro no es el coordinador, pero puede escogerse
igualmenteapartirdelospesosasignadosacadamiembro.
Cada miembro sin estado selecciona un coordinador. No hay comunicaciones
entreestosmiembros,porloquenosesoportabalanzadecarga.Elcoordinador
recibeunmensajerdesolicituddeestado(requeststatemessage).
Elcoordinadorenvaentonceselestadoenmensajess.
Alconcluirlatransferencia,elmiembrosinestadoenvaunmensajemultipunto
e, indicando as su promocin a miembro con estado. En este mensaje incluye
suspropiedades.
Si el coordinador se cae, el miembro sin estado selecciona un nuevo
coordinador mediante un mensaje r, donde incluye el estado actual de la
transferencia. En este caso, no es necesario que ninguno de los miembros con
estado enve de nuevo el mensaje p, puesto que al ser multipunto, pueden saber
perfectamentesielnuevomiembrolorecibiono.
Varios miembros sin estado pueden seleccionar al mismo coordinador para
realizar la transferencia de estado. Si esta concurrencia no es deseable, deber
inhibirse en algn nivel por encima de este protocolo. Tambin se definir de esta
maneraelcontenidodelmensajer,talcomosevioenlatransferenciapush.
6.4.Transferenciapush-onestep
El protocolo push puede simplificarse cuando el estado se transfiere en un
solo mensaje, mediante el protocolo push-one step. En este caso, se selecciona un
nico coordinador que transfiere el estado en un mensaje multipunto, que incluye
asimismo las propiedades de los miembros con estado. Cada miembro sin estado
deberealizarasuvezunenvodesuspropiedadesconunmensajemultipunto.
A pesar delnombre,elprotocolopushanpuedeusarseparatransferencias
enunnicopaso,ycomoseveenlasiguientecomparativa,staeslasolucinms
favorableenlamayoradeloscasos.
6.5.Comparativasdeprotocolos
6.5.1.Protocolospushypush-onestep
Las figuras 6.3 y 6.4 comparan los protocolos push y push-one step para
pequeos estados, asumiendo que el coordinador elegido no se cae durante la
transferencia. Los grficos comparan la cantidad de informacin enviada en ambos
protocolosparadistintostamaosdeestado,indicandolosvalorespositivosunpeor
rendimientoparaelprotocolopush.Laprimerafiguraserefierealcasodondenose
usanpropiedades,ylasegundafiguraincluyeelsoportedepropiedades.
Losclculossehanrealizadoconunostamaosdecabeceradelosmensajes
de32bytesytamaosdeidentidadesdelosmiembrosdelgrupode6bytes.Paralas
propiedades, se han empleado pequeos tamaos, con slo 10 bytes por miembro.
Finalmente,losmensajescdecoordinacinenelprotocolopushsehanconsiderado
con tamaos de 4 bytes, suponiendosimplementedoscontadoresenteros,unoque
indiquelafasedelatransferenciayotroparaelnmerototaldefasesrequeridas.Se
observa que el protocolo en un slo paso tiene mejor comportamiento para estados
pequeos, y se degrada rpidamente segn aumenta el nmero de miembros del
grupo;estecomportamientoseacentasiseaumentanlostamaosdelascabeceras
delosmensajesodelaspropiedades:
Como el protocolo push-one step realiza la transferencia en un solo mensaje
multipunto,lainclusinsimultneadevariosmiembrosenelgruporepercuteen
unmejorcomportamientodeesteprotocolo.
Elempleodepropiedadessuponeenelprotocolopush-onestepelenvoadicional
de un mensaje multipunto por cada nuevo miembro, lo que se traduce en un
peor rendimiento respecto al protocolo normal, tanto peor cuanto mayores sean
esaspropiedades.
Figura 6.3.Comparativaentre push ypush-onestep,sinpropiedades.
Valorespositivosimplicanpeorrendimiento del protocolo push.
1000
-250
Statesize
100
Miembros
3
6
200
Nuevosmiembros
1
2
miembros
Los grficos se han realizado suponiendo que no hay soporte multipunto; con
ste,elprotocoloenunsolopasoresultarsiemprepreferiblealprotocolopush,
alhacerusoextensivodelosmensajesmultipunto.
Porlotanto,sinsoportemultipunto,elempleodetransferenciaconprotocolo
push-one step se limita a estados muy pequeos, tanto ms segn aumenta el
tamao del grupo, y dando muy mal rendimiento si es necesario el soporte de
propiedades. Debe notarse que, lgicamente, el protocolo push tambin permite
transferenciasenunnicopaso,dondeseenvaunnicomensajes.
6.5.2.Protocolospushypull
Lafigura6.5muestraladiferenciaenlacantidaddeinformacinenviadaen
transferencias push y pull, segn el nmero de miembros del grupo. Valores
positivos indican mejor rendimiento delprotocolopull;losclculossehanrealizado
con los mismos parmetros (tamaos de mensajes, etc.) que se han detallado en la
comparativaentreprotocolospushypush-onestep:
Cuantomayoreseltamaodelgrupo,mejorescomparativamenteelrendimiento
del protocolo push. Esto se debe al mayor nmero de mensajes necesarios para
realizar un envo multipunto; por esta misma razn, un aumento en el tamao
delosmensajescomo,porejemplo,emplearcabecerasmayores,implicaunpeor
rendimientodelprotocolopull.
Figura 6.4.Comparativaentre push ypush-onestep,con propiedades.
Valorespositivosimplicanpeorrendimiento del protocolo push.
Miembros
3
6
Nuevosmiembros
1
2
350
-750
Statesize
100
miembros
La inclusin simultnea de varios miembros en el grupo repercute en un mejor
comportamientodelprotocolopull.
El uso de propiedades implica un mayor tamao de los mensajes multipunto
necesariosbajoprotocolopull,loquesetraduceenunpeorrendimientodeeste
protocolosegneltamaodelaspropiedadesaumenta.
Consoportemultipunto,esfavorableelempleodelprotocolopull.
Resumiendo: sin soporte multipunto, el protocolo push tiene un mejor
comportamientoqueelprotocolopull,beneficindoseesteltimodesituacionescon
muy frecuentes cadas de miembros y de inclusiones simultneas de nuevos
miembros en el grupo. Con soporte multipunto, el protocolo pull tiene mejor
rendimiento.
6.6.GMSconsoportedetransferenciadeestado
Aunque el GMS no implemente los protocolos de transferencia de estado,
puede incluir un soporte bsico si aade en cada vista informacin sobre los
miembros con estado. De esta forma, los nuevos miembros conocen desde el
principio los miembros con estado, si los hay. Este soporte podra adems
extenderseparaincluirasimismolaspropiedadesdelosmiembros.
El impacto en el GMS es muy pequeo, y es nicamente preciso que los
miembros que adquieren el estado del grupo lo comuniquen al GMS para que ste
Figura 6.5.Comparativaentreprotocolos push ypull.
c
a
e
b
d
miembros
160
f
g
(a):un nuevomiembro
(b):la terceraparte de los
miembros sonnuevos
(c):un nuevomiembro,
usandopropiedades
(d):muchosmiembros
nuevos (la sextaparte),
con frecuentescadas
decoordinadores
(e):como (d),usando
propiedades
(f):como (a),con soporte
multipunto
(g):como (e),con soporte
multipunto
pueda instalar una nueva vista. Obviamente, este soporte mnimo est orientadoal
protocolo pull, donde hace falta que los nuevos miembros reciban primero
informacin sobre el estado del grupo para poder dirigirse entonces a un miembro
vlidoysolicitarleelestado.
La figura 6.6 muestra los cambios en el protocolo push. El coordinador,una
vez transferido el estado, comunica al GMS la actualizacin del nuevo miembro, en
lugar de enviar un mensaje multipunto a todo el grupo. El GMS instalar
eventualmente, posiblemente tras esperar a que todos los nuevos miembros hayan
recibidoelestado,unanuevavistaqueincluyelanuevainformacindeestado.
Lafigura6.7muestraloscambiosenelprotocolopullque,alnoprecisardel
primer mensaje multipunto p, resulta claramente superior al protocolo inicial. Una
comparacin entre el protocolo push sin soporte del GMS y el protocolo pull con
soporte, clarificaracundolainclusindetalfuncionalidadenelGMSresultatil.
No obstante, tal comparativa depender de la implementacin particular de las
vistas en el GMS. As, si cada vista implica un mensaje multipunto entre los
miembros del GMS incluyendo slo los cambios y no la vista completa, la
informacinaenviarbajoprotocolopullesmenoryelsoportedelatransferenciade
estadoenelGMSquedajustificado.
Tanto Maestro [Vaysburd98] como JavaGroups [Ban98] (ambos sobre
Ensemble) utilizan transferencia pull, pero en ambos casos se elimina el mensaje
inicial que enva unmiembroconestadoparainformardeculessonlosmiembros
correctos que pueden realizar la transferencia; el primero realiza la suposicin
errneadequelavistaincluyelosmiembrosmsantiguosconlosrangosmsbajos,
Figura 6.6.Protocolo push con soporte de transferencia enelGMS
p
s
p
c s
v
g
v
GMS
c
Mensajes
(c): coordinarestado
(g): estadoobtenido
(v): vistadelgrupoydeestado
Nueva
vista
porloqueelmiembrosinestadosiempresedirigealmiembroconmenorrango.En
JavaGroups, el miembro sin estado se dirige a cualquiera de los dems miembros,
sin saber si tiene estado o no; si no le responde en un tiempo determinado, la
solicitaaotromiembro.
6.7.Gruposparticionables
Si el GMS presta soporte de estado, en el caso de grupos de particiones
primarias basta con que contenga constancia de los miembros con estado. Si el
grupoesparticionable,debeagruparlosmiembrossegnelestadoqueposean,pues
distintosmiembrospuedenpresentarestadosinconsistentes,yelGMSadmitirdos
nivelesdesoporte:
Asociar a cadamiembrounidentificadornicodeestado,queesenviadoenlas
vistas.
Implementar la interfaz definida en [Babaoglu95] en sincrona virtual extendida,
unaformadeagruparlosmiembrossegnsuestadoypermitiralaaplicacinla
integracindesubvistasyconjuntosdesubvistashastaalcanzarunestadonico
(unavistanica).
Senseinoincluyeelestudiodegruposparticionables,porloquelimitamoslos
protocolosdetransferenciaalosgruposprimarios.
Figura 6.7.Protocolo pull con soporte de transferencia enelGMS
s
r s
v g
v
GMS
r
Mensajes
(r): solicitarestado
(g): estadoobtenido
(v): vistadelgrupoydeestado
Nueva
vista
6.8.Conclusiones
Este captulo se ha centrado en los protocolos de bajo nivel necesarios para
realizar la transferencia de estado en grupos primarios. Hay dos enfoques posibles:
un miembro con estado se dirige al nuevo miembro y le transfiere el estado, o el
nuevomiembroobtieneinformacinsobreelgrupoysedirigeentoncesaunodelos
miembrosconestadoparasolicitarlelatransferencia.
Para cada posibilidad, hemos desarrollado un protocolo de bajo nivel que
permite implementar protocolos de aplicacin flexibles, como demostramos en el
siguiente captulo. Finalmente, hemos verificado las condiciones que favorecen el
empleo de uno u otro protocolo. Estas condiciones han incluido el uso de
propiedades o no, y el posible soporte por parte del GMS para la transferencia de
estado,estudiandoelimpactodelnmerodemiembrosenelgrupoydelnmerode
nuevos miembros en cada vista. Aunque para la comparativa hemos partido de
valores precisos para los tamaos de los mensajes, hemos observado tambin el
impactodevariacionesenesostamaos.
Como regla general, el protocolo push precisa una menor transferencia de
informacin, salvo que se disponga de soporte multipunto. Como contrapartida, es
ms complicado de implementar, pues cada miembro debe mantener el estado de
transferenciadetodoslosdemsmiembros.
Interfazdeaplicacindetransferenciadeestado 87
Captulo7-INTERFAZDEAPLICACIN
DETRANSFERENCIADEESTADO
Losdoscaptulosanterioreshanespecificadounalgoritmodetransferenciade
estado y unos protocolos de bajo nivel sobre losqueimplementaresatransferencia
de estado. Este captulo se centra en la interfaz de alto nivel que la aplicacin
emplear, interfaz que permite la implementacin del algoritmo de transferencia de
estadoplanteado.
Esta interfaz la especificaremos como un servicio CORBA, en OMG/IDL, as
como en Java, y mostraremos su implementacinsobrelosprotocolosdebajonivel
descritosenelcaptuloanterior.
El Object Management Group ha aprobado recientemente el servicio estndar
de tolerancia a fallos en CORBA mediante replicacin de entidades [OMG99]. Esta
especificacinserefierealareplicacindeobjetosenunentornoCORBA,eintenta
soportar un amplio rango de requisitos. Incluye soporte de replicaciones activa y
pasiva. Permite el control de la creacin y consistencia de las rplicas por la
aplicacin o bien por la infraestructura de tolerancia a fallos. Realiza el
mantenimiento y recuperacin del estado, ya sea automticamente o personalizado
segn la aplicacin. Y este soporte se proporciona intentando minimizar en todo
casoelimpactosobreelORB.
Sinembargo,laespecificacindejaalmenosunpuntoabierto:latransferencia
deestadoengruposderplicasactivasconunestilodeconsistenciacontroladopor
la aplicacin, transferencia que debe ser suficientemente flexible para soportar los
requisitosdemuyvariadasaplicaciones.
7.1.ToleranciaafallosenCORBA
El principal componente en la especificacin de tolerancia a fallos de CORBA
para el manejo de grupos de objetos es el ReplicationManager, o supervisor de
replicacin,quedeberareplicarseasuvezparaassertoleranteafallos.Lainterfaz
del ReplicationManager soporta por herencia las tres interfaces siguientes:
PropertyManager (supervisor de propiedades), GenericFactory (factora de grupos) y
ObjectGroupManager(supervisordegruposdeobjetos).
LainterfazPropertyManagerdefinepropiedadesdetoleranciaafallosengrupos
deobjetos,quedeterminanlasresponsabilidadesdelainfraestructuradetolerancia
a fallos. Las propiedades ms relevantes son ReplicationStyle (estilo de replicacin),
MembershipStyle (estilo de pertenencia a grupo) y ConsistencyStyle (estilo de
consistencia).
La propiedad ReplicationStyle determina cmo se mantiene el estado en las
rplicas; puede ser stateless (sin estado), cold passive (estado pasivo fro), warm
passive (estado pasivo caliente), active (estado activo) y active with voting (estado
activoconvotacin),aunqueelltimonoestsoportadoenlaactualespecificacin.
Las replicaciones pasivas se basan en que un nico miembro, llamado primario,
procesatodaslassolicitudesdeserviciodirigidasalgrupo,grupoquecontieneotros
miembrosdenominadospasivosobackup.Silareplicacinescaliente,losmiembros
pasivosrecibenperidicamenteelestadodelarplicaprimaria;siesreplicacinfra,
la actualizacin se realiza nicamente cuando es estrictamente necesario porquela
rplica primaria se haya cado. Bajo replicacin activa, todas las rplicas procesan
todas las solicitudes de servicio al grupo, y se suprimen tanto las solicitudes
repetidascomolasrespuestasduplicadas.Esteestilorequierequeelgruposedisee
bajoelmodelodesincronavirtual[Birman87].
La propiedad MembershipStyle determina como se maneja la pertenencia al
grupo,siesdirectamentecontroladaporlaaplicacin(application-controlled)oporla
infraestructura de tolerancia a fallos (infrastructure-controlled). En el ltimo caso, el
ReplicationManager invocar a las factoras requeridas para crear los miembros
necesarios para satisfacer las propiedades del grupo, como el nmero inicial o
mnimo de rplicas. Si la aplicacin controla la pertenencia al grupo, el
ReplicationManager dispone de operaciones para insertar o extraer miembros de los
grupos,definirelmiembroprimarioylaslocalizacionesdecadamiembrodelgrupo.
La consistencia del grupo, determinada por la propiedad ConsistencyStyle,
puede ser tambin controlada por la aplicacin (application-controlled) o por la
infraestructura (infrastructure-controlled). En el primer caso, la aplicacin debe
asegurar su propia consistencia en cada momento: tras invocaciones al grupo o
cuandostecambiaporqueunanuevarplicaesaadidaalgrupo,lacualdebepor
lo tanto recibir el estado actual del grupo.Alternativamente,siescontroladaporla
infraestructura de tolerancia a fallos, los objetos que soportan la aplicacin deben
implementar una interfaz bsica, Checkpointable, que define operaciones simples
paraobteneroestablecerelestado:
interfaceCheckpointable{
Stateget_state();
voidset_state(inStates);
};
interfaceUpdateable:Checkpointable{
Stateget_update();
voidset_update(inStates);
};
Opcionalmente, los objetos pueden implementar una interfaz especializada
sobrelaanterior,Updateable,quedefineadicionalmenteoperacionesparaestablecer
y obtener el estado incrementalmente. La infraestructura maneja los mecanismos
requeridosparamantenerunaconsistenciafuerteentrelasrplicasdegrupoypara
instalar un estado consistente en cada nueva rplica. Esta consistencia significa,
bajo replicacin pasiva, que tras la transferencia de estado a un miembro pasivo,
ste es consistente con la rplica primaria o, si la replicacinpasivaescold,conla
anteriorrplicaprimera.Conreplicacinactiva,consistenciafuerterequierequetras
cada invocacin de servicio al grupo, toda rplica tenga el mismo estado. Si la
replicacin mantiene algn estado, es decir, no es stateless, el comportamiento de
cada miembro debe ser determinista y cada miembro debe comenzar en el mismo
estado.
Esta especificacin implica que, cuando la infraestructura de tolerancia a
fallos debe mantener laconsistencia,lasrplicasdebendevolverperidicamentesu
estado. Esta infraestructura almacena los mensajes procesados por cada rplica y
obtienesuestadoenintervalosperidicosacordesalapropiedadCheckpointInterval,
definida en unidades de dcimas de microsegundos. Al incorporarse una nueva
rplica al grupo, el estado de ste puede obtenerse a partir del ltimo estado
almacenadoydelosmensajesprocesadostrashaberalmacenadoeseestado,deah
lanecesidaddelcomportamientodeterministadelaaplicacin.
La transferencia de estado estudiada en Sensei involucra precisamente a los
gruposderplicasactivasdondeelestadoseobtieneapartirdelasotrasrplicasde
formadirecta.BajolanotacinCORBA,eldominiodeSenseisonlosgruposactivos
con un valor de la propiedad ConsistencyStyle tal que la consistencia es manejada
por la propia aplicacin. Finalmente, la especificacin CORBA no soporta el
particionado de grupos, por lo que no es necesario incluir la consistencia entre
gruposparticionados.
7.2.Diseodelainterfaz
La interfaz que especificamos busca la flexibilidad necesaria para adaptarse a
complejos requisitos de transferencia. Sin embargo, debe mantenerse simple en los
casos que precisentransferenciassencillas.Porestarazn,unmiembroquerealice
transferencias en un nico paso debe implementar simplemente la interfaz
Checkpointable, tal como lo define la especificacin CORBA. Bajo JavaRMI, esta
interfazes:
publicinterfaceCheckpointableextendsjava.rmi.Remote{
Stateget_state()throwsjava.rmi.RemoteException;
voidset_state(States)throwsjava.rmi.RemoteException;
}
Dondeelestadovienedefinidocomo:
publicinterfaceStateextendsjava.io.Serializable{}
Lossiguientesapartadosimplicanunamayorflexibilidadenlatransferencia:
Transferenciasenvariospasos.
Comportamientoantecambiosdevistas.
Propiedadesdemiembros.
Eleccindelcoordinador.
Transferenciasconcurrentes.
Cada apartado es explicado a continuacin, antes de mostrar la interfaz
especificada. Al describir esta interfaz, los objetos o clases involucrados han sido
nombrados en ingls, para mantener la coherencia con otras especificaciones
OMG/IDL.
7.2.1.Transferenciasenvariospasos
Cuando se transfiere el estado en varias partes, se precisa alguna
sincronizacinentreelcoordinadoryelnuevomiembroparaidentificarlaparteque
se transfiere. Esta sincronizacin puede definirse simplemente por el orden de las
partesquesetransfierepero,especialmenteparasoportarunprotocolobidireccional
entre ambas partes que permitareanudartransferenciasinterrumpidas,serequiere
algn mecanismo ms elaborado de sincronizacin. Aunque la misma porcin de
estado puede incluir esa sincronizacin como parte del estado, definir un objeto
separado para ese propsito permitir un diseo mejor y ms claro. Este objeto lo
llamamos coordinacin de fase o PhaseCoordination en la interfaz, y es la propia
aplicacinquienlodefine.
Desde el punto de vista del sistema de transferencia de estado, esta fase
simplemente debe indicar cundo una transferencia ha concluido. Un ejemplo es
una fase que contiene el nmero de porciones en que se ha dividido el estado y la
identidad de la siguiente porcin a transferir. El final de la transferencia se
determina en este caso cuando la identidad y el nmero de porciones del estado
coinciden.EstafasesedefineenOMG/IDLcomo:
valuetypePhaseCoordination{
publicbooleanis_transfer_finished();
}
Unafasequesiempredevuelvetruedefineunatransferenciaenunnicopaso,
obviamente.
LadefinicindeesteobjetoserealizaenCORBAmediantelafuncionalidadde
objetos por valor. Si en su lugar se hubiera empleado un tipo interface, chequearla
finalizacin de la transferencia requerira una llamada remota. Y si en su lugar se
empleara un tipo struct, no habra posibilidad de extenderlo para incluir
comportamientoespecficoparalaaplicacin,puesnoadmitenherenciaenCORBA.
Deestaforma,sepuededefinirlafasedelanteriorejemplodelasiguientemanera:
valuetypeExamplePhase:PhaseCoordination{
publiclongchunks;
publiclongnextChunk;
};
Cuando se accede al coordinador para obtener su estado, debe devolver un
objeto PhaseCoordination asociado a ese estado, que es transferido al nuevo
miembro.Casitodaslasoperacionesenlainterfazdetransferenciaincluyenfasesde
coordinacin.
BajoJavaRMI,ladefinicindelafasees:
publicinterfacePhaseCoordinationextendsjava.io.Serializable{
publicbooleanis_transfer_finished();
}
Alserserializable,elobjetoqueimplementelainterfazesvistolocalmenteenla
mquinavirtualquelorecibeyelaccesoasusmtodosnoesremoto.
7.2.2.Cambiosdevistas
Si una transferencia se interrumpe porque el coordinador haya cado, es
posible que el nuevo miembro enve con una fase la informacin sobre esa
transferenciainterrumpidaasunuevocoordinador,detalmaneraquenotengaque
reiniciarsedesdeelprincipio.
Sin embargo, como ya hemos demostrado al estudiar las condiciones en la
transferencia, la sincronizacin entre el nuevo miembro y el coordinador, cuando
unatransferenciaanterioresinterrumpida,noesenabsolutounprocesoobvio.As,
la solucin genrica que propusimos fue la de cancelar toda transferencia que no
hubiese finalizado cuando una nueva vista se instalase. En principio, hay dos
soluciones alternativas, aunque debe notarse que no son completamente
compatiblesconelmodelodesincronavirtual,alromperunodelosprincipios:dos
miembros cualesquiera en dos vistas consecutivas deben procesar los mismos
mensajes.
La primera solucin implica que, cuando se realiza la transferencia, tanto el
coordinador como el miembro coordinado se encuentran lgicamente fuera del
grupo:ningunoprocesaningnmensajehastaquesecompletelatransferencia.Siel
coordinador se cae, el miembro coordinado debe ser capaz de enviar a su nuevo
coordinador informacin sobre el estado recibido y los mensajes procesados, de tal
maneraquestepuedaconocerlaporcindeestadoquelefalta.Losmensajesson
por lo tanto encolados, no siendo procesados hasta que la transferencia finalice
naturalmenteoporqueunodelosparticipantesenlatransferenciasecaiga.Siesel
coordinador el que se cae, los mensajes encolados en el nuevo miembro son
eliminadosdelacola.
Estasolucineslaquepermiteunatransferenciadeestadomssencillapara
la aplicacin, que se despreocupa de los cambios de vista. El objetivo que se
persigueconelmodelodesincronavirtualesobtenerestadosconsistentesmediante
elprocesadodelosmismosmensajesenunordenadecuado.Sielprocesadodeun
mensaje depende de informacin de la vista como, por ejemplo, del nmero de
miembrosenelgrupo,nopodremplearseestasolucin.
La otra solucin implica que slo el miembro coordinado se encuentrafuera
del grupo durante la transferencia. Si llega una nueva vista, los mensajes son
enviados al coordinador para que los procese, mientras que el miembro coordinado
puede,biendescartar,bienrecibir,todoslosmensajesdeesavista.Lamotivacinde
esta solucin es permitir al coordinador evaluar los cambios en el estado, cambios
quepuedeenviarenunavistaposterior.
Estasegundaopcinessimilaralasolucinquepropusimoscomogenrica:
ambos miembros reciben todos los mensajes, pero si hay un cambio de vista la
transferencia se reinicia automticamente. En este caso, se deja a la aplicacin la
opcin de que reinicie esa transferencia o pueda evaluar todosloscambiosque,en
algunoscasos,puedesuponerunaoptimizacinalprotocolo,acostadecomplicarla
lgicadelaaplicacin.
Para permitir las distintas opciones, un parmetro permite definir cmo se
realiza la transferencia. Esta propiedad en el sistema de transferencia de estado la
denominamosBehaviourOnViewChangesypuedetomarlossiguientesvalores:
MembersOnTransferExcludedFromGroup: los miembros en la transferencia se
consideranexcluidosdelgrupo.Losmensajesquedanencoladosysloseenvan
alaaplicacincuandolatransferenciahaconcluido.
StatelessMembersDoNotBelongToGroup:losmiembrossinestadonopertenecenal
grupo. Estos miembros no recibenmensajesentantonorecibanelestado;ante
uncambiodevista,latransferenciaseconsideraquedebereiniciarse,aunquese
mantiene el mismo coordinador para permitir optimizaciones. El servidor no
procesamensajesentantorealizalatransferenciapero,anteuncambiodevista,
interrumpestayrecibetodoslosmensajesnoprocesadosenesavista,quedebe
procesarantesdeasumirlanuevavista.
StatelessMembersBelongToGroup: todos los miembros se consideran incluidosen
el grupo. sta es la nica opcin que permite una solucin que se adhiere al
modelodesincronavirtual.Secomportacomoenelanteriorcaso,peroelnuevo
miembro recibe los mensajes antes de procesar la nueva vista y es
responsabilidad de la aplicacin el realizar toda la sincronizacin necesaria, o
bien, descartar toda resincronizacin y comenzar de nuevo la transferencia. Los
mensajessloseenvanalfinaldelavista,nodurantesta,ylaaplicacindebe
decidirsilospuedeprocesarono.
7.2.3.Propiedadesdemiembros
El estado del grupo puede entenderse como el estado de un determinado
miembro que fuera el nico miembro de ese grupo. Sin embargo, las propiedades
estn asociadas a cada miembro en particular y no tienen visibilidad fuera del
grupo,esdecir,nisonpartedelestado,nideberanafectaralresultadodeninguna
operacinsobreelgrupo.Lasoperacionesrelativasalmismogrupospuedenverse
afectadas y un ejemplo es la eleccin del coordinador. Ejemplos bsicos de estas
propiedadessonlaslocalizacionesdecadamiembroopesosespecficospararealizar
determinadastareas.
Otra diferencia entre el estado y las propiedades de los miembros reside en
su transferencia. Cuando un nuevo miembro se incluye en el grupo, el grupo
transfiere su estado a este miembro. Sin embargo, las propiedades deben
transmitirse en ambas direcciones: se considera que un nuevo miembro no tiene
estadoperospropiedades.
La especificacin de tolerancia a fallos en CORBA define una estructura de
propiedadesllamadaProperty,quepodemosemplearparaestepropsito:
typedefCosNaming::NameName;
typedefanyValue;
structProperty{
Namenam;
Valueval;
};
typedefsequence<Property>Properties;
LadefinicindepropiedadesbajoJavaRMIes:
classPropertyimplementsjava.io.Serializable{
publicinterfaceValueextendsjava.io.Serializable{}
publicStringnam;
publicValueval;
}
LainterfazPropertyManagerenlaespecificacinCORBAdefinemtodospara
asociar estticamente propiedades por defecto para cualquier grupo creado por ese
manager, o dinmicamente para un grupo especfico. Por su complejidad, los
detalles del manejo de propiedades lo posponemos a una seccin posterior y slo
definimosaqulainterfazOMG/IDLquedebensoportarlosmiembrosdelgrupopara
recibirlasnotificacionesdecambiosenlaspropiedadesdeotrosmiembros:
interfacePropertyListener{
voidproperties_updated(inLocationloc);
};
7.2.4.Eleccindelcoordinador
Hay varias estrategias para seleccionarelmiembroresponsabledecoordinar
una determinada transferencia de estado: transferencia pull, donde el nuevo
miembro selecciona a ese coordinador, o transferencia push, donde son los
miembros con estado los que lo seleccionan. El captulo anterior mostr que el
protocolo push presenta un mejor rendimiento en aquellos casos en que no se
dispone de soporte multipunto por hardware: por esta razn, el servicio de
transferenciadebepredefinirsecomopushopull,yaquenoesposiblequeelservicio
seleccioneautomticamenteelmejormododefuncionamiento.
Bajo las dos estrategias, la eleccin del coordinador puede realizarse
automticamente por la infraestructura de transferencia de estado, o bien
directamente por la aplicacin. En el primer caso, la aproximacin ms sencilla es
permitir que cualquier miembro sea el coordinador. Una posibilidad ms elaborada
es asociar pesos a cada miembro, permitiendo as balancear la carga de
transferenciaentrelosmiembrosconestado,obienasignarlastransferenciasauno
ovariosmiembrospredeterminados,aquellosquetenganmayorespesos.
Cuando la aplicacin selecciona al coordinador, los miembros deben
implementar la interfaz CoordinatorElector, que define nicamente un mtodo
denominado get_coordinator, mtodo que, al ser invocado, debe devolver
determinsticamenteunodelosmiembrosconestadopresentados:
interfaceCoordinatorElector{
Locationget_coordinator(inLocationslocs);
};
CORBA define Location como CosNaming::Name, que es a su vez un string.
Por lo tanto, los miembros vienen identificados por una cadena de caracteres y la
aplicacin selecciona alcoordinadorapartirdeestasidentificaciones.Enelmtodo
anterior, slo los miembros con estado, susceptibles de ser coordinadores, son
enviadosenelnicoparmetro.
La operacin debe ser determinista, todos los miembros consultados deben
devolver el mismo miembro; sin embargo, si el protocolo empleado es pull, es
responsabilidadexclusivadelnuevomiembroelescogeresecoordinador,porloque
enestecasoesedeterminismonoesnecesario.
Cuandolainfraestructuraseleccionaalcoordinador,elalgoritmoesdiferente
para protocolo push y pull. En el primer caso, se balancea la carga sobre los
distintosmiembrosconestadoy,enelsegundocaso,seseleccionaelcoordinadorde
acuerdoconsurangoenlavista:elmiembrosinestadoconmenorrangoselecciona
al miembro con estado con menor rango, etc. Debe notarse que este segundo
algoritmonobalancearealmentelacarga.Porejemplo,siunavistainstalaunnuevo
miembroy,antesdequeconcluyasutransferencia,seinstalaunasegundavistacon
otronuevomiembro,ambosseleccionanelmismocoordinador.
Para dar una mayor flexibilidad a este esquema, este algoritmo permite
definir una determinada propiedad que denominamos peso del coordinador. Si esta
propiedadestdefinidaytieneasociadounvalornumrico,seentiendecomoelpeso
quecadamiembrotieneparaserseleccionadocomocoordinador.
7.2.5.Concurrenciaenlatransferencia
Sielgrupocontienemsdeunmiembrosinestadoconsistente,esnecesario
realizar ms de una transferencia. Estas pueden realizarse simultneamente si hay
varios coordinadores o bien cuando un nico coordinador las realiza
concurrentemente.Laprimeraaproximacindependedelaeleccindelcoordinador,
cuando dos miembros sin estado seleccionan diferentes coordinadores. La segunda
opcin tiene dos posibilidades, que pueden determinarse de nuevo mediante
propiedadesenelsistemadetransferenciadeestado.Estasdosposibilidadesnoson
mutuamenteexcluyentes.
En primer lugar, definimos la propiedad booleana
ConcurrentTransfersAllowed, describiendo cundo un servidor puede realizar
simultneamente transferencias independientes a distintos clientes. Esta opcinno
escompatiblelgicamenteconqueelservidorseencuentrefueradelgrupoentanto
se realiza la transferencia: si inicia una transferencia en una vista y antes de
concluirla se instala una nueva vista con un nuevo miembro y debe transferirle
igualmente el estado, habr un desfase lgico debido a los mensajes de la vista
anterior que no ha podido procesar. Porestarazn,lastransferenciasconcurrentes
slo pueden realizarse, en este caso, sobre miembros que la inician en la misma
vista.
La segunda posibilidad viene definida con la propiedad booleana
MultipleTransfersAllowed: el servidor realiza la transferencia a varios clientes
simultneamente y todos reciben el mismo estado. Esto implica que todos deben
devolverlamismacoordinacindefaseencadapaso.Sialgunonoladevuelve,debe
considerarsequefuncionaerrneamenteyserexpulsadodelgrupo.
7.3.Interfazdetransferencia
La seccin anterior mostr varios aspectos que influyen directamente en la
interfaz final: las transferencias pueden realizarse en varios pasos, pueden ser
interrumpidas al cambiar las vistas y pueden incluir concurrentemente varios
miembroscoordinados.
La interfaz se define, entonces, incluyendo en cada mtodo las fases de
coordinacin que hemos definido, que permiten realizar la sincronizacin en las
transferencias en varios pasos y en las transferencias interrumpidas. La siguiente
listamuestralosmtodosquedebensoportarse,sindetallarsufuncionalidad:
start_transfer: se invoca sobre el coordinador, que devuelve una fase a emplear
enlossiguientespasosdelatransferencia.Elcoordinadorrecibeaqulalistade
miembrosacoordinar,encasodeunatransferenciaconcurrente.
stop_transfer: se invoca, tanto sobre el coordinador, como sobre el nuevo
miembro, para indicar el final de una transferencia de estado, bien porque sta
hayafinalizado,bienporqueunodelosmiembrosenlatransferenciahayacado.
get_state: en comparacin con el mtodo con el mismo nombre en la interfaz
Checkpointable, incluye ahora un parmetro con la fase que se espera y la
siguiente fase a enviar. A partir de la fase que se devuelve, el sistema de
transferenciadeestadoobtienelainformacinnecesariaparasabercundouna
transferenciahafinalizado.
set_state incluye tambin un parmetro con la fase asociada al estado que se
establece.
sync_transfer:invocadosobreelnuevomiembroparaobtenerculeslafaseque
espera.Seinvocaalprincipiodelatransferenciaytrasinstalarsecadavista.En
el caso de emplear la aproximacin donde se consideran que los miembros en
transferencia estn excluidos del grupo
(MembersOnTransferExcludedFromGroup),seinvoca,lgicamente,unanicavez.
interrupt_transfer: se invoca sobre el coordinador y sobre el nuevo miembro en
cada momento en que la transferencia quede interrumpida. En el caso de
MembersOnTransferExcludedFromGroup no se invoca, entonces, en ningn
momento.
continue_transfer: invocacin al reanudarse una transferencia. Tampoco se
invocanuncaenelcasodeMembersOnTransferExcludedFromGroup.
Estos mtodos se especifican en una nueva interfaz, StateHandler, que no
tienenningunarelacindedependenciaconlainterfazCheckpointable.Sinembargo,
enlugardeespecificarunanicainterfaz,lafuncionalidadquedadesglosadaendos
interfacesconrelacindeherencia,laprimeradeloscualessoportalafuncionalidad
del caso ms simple, donde toda transferencia queda cancelada tras un cambio de
vista.LainterfazmssimpleesBasicStateHandler,quebajoOMG/IDLes:
interfaceBasicStateHandler{
voidstart_transfer(inLocationsjoining_members,
inoutPhaseCoordinationphase);
Stateget_state(inoutPhaseCoordinationphase);
voidset_state(inStates,
inPhaseCoordinationphase);
voidstop_transfer(inLocationsfalling_members,
inbooleantransfer_finished);
};
Esta interfaz queda especializada, en el caso de poder continuar
transferenciasinterrumpidas,mediantelainterfazStateHandler:
interfaceStateHandler:BasicStateHandler{
voidsync_transfer(inLocationcoordinator,
voidinterrupt_transfer(inoutPhaseCoordinationphase);
voidcontinue_transfer(inLocationsjoining_members,
inoutPhaseCoordinationcoordinator_phase,
inPhaseCoordinationjoining_phase);
};
La interfaz resulta compleja para poder soportar todas las posibilidades de
transferencia. Aun as, resulta mucho menos compleja que la lgica que la propia
aplicacin debe incluir para soportar transferencias interrumpidas. La seccin
posterior de ejemplos de uso muestra esta complejidad y cmo la interfaz definida
permitesoportarlasdistintasposibilidades.
7.3.1.sync_transfer
Esta operacin, slo soportada en la interfaz ms compleja, StateHandler, se
invoca sobre el nuevo miembro cuando se va a iniciar la transferencia y, a
continuacin,trascadainterrupcindetransferenciadebidaacambiosdevistas,de
tal forma que el miembro pueda devolver una fase de coordinacin que exprese su
actualestadodetransferencia.
voidsync_transfer(inLocationcoordinator,inoutPhaseCoordinationphase);
El primer parmetro informa sobre el coordinador asignado y el segundo
parmetro devuelve la fase esperada. Si haba ya una transferencia en curso,
cancelada por la cada del coordinador previo, este mtodo se invoca con la ltima
fase devuelta al recibir una notificacin interrupt_transfer, que ser una referencia
nulaenotrocaso.
Si dos miembros susceptibles de pertenecer a la misma transferencia
simultnea devuelven dos fases distintas, no podrn recibir el mismo estado
simultneamente.
7.3.2.start_transfer
Esta operacin se invoca sobre el coordinador cuando se inicia una
transferencia, para permitir cualquier preprocesado que la aplicacin precise, y
podersincronizarlatransferenciaconelnuevomiembro.
voidstart_transfer(inLocationsjoining_members,inoutPhaseCoordinationphase);
El primer parmetro incluye las localizaciones de los miembros nuevos, que
tendrn la misma transferencia de estado. Si la aplicacin soporta transferencias
concurrentes de un coordinador a varios miembros, cada uno de ellos bajo una
transferencia diferente, este mtodo es invocado repetidamente para cada uno de
esosmiembros,enlugardeincluirlosatodosenelprimerparmetro.
Si se soporta slo la interfaz BasicStateHandler, el segundo parmetro no
contiene ninguna informacin vlida. En caso contrario, antes de invocarse esta
operacin, el sistema habr solicitado al nuevo miembro su fase de coordinacin
empleandoelmtodosync_transfer,yestafasesetransfiereahoraalcoordinador.
Devuelve, en ese mismo segundo parmetro, una fase que se emplear en la
siguientellamadaaget_state.
7.3.3.get_state
Como en el caso de su operacin homnima en la interfaz Checkpointable,
get_state devuelve el estado de un miembro del grupo y se invoca, exclusivamente,
sobremiembrosquepresentenunestadoconsistente.
Stateget_state(inoutPhaseCoordinationphase);
Elestadooporcindeestado,sedevuelveconelprimerparmetro;elsegundo
parmetro contiene la fase que determina el estado o porcin de estado a devolver,
proveniente de una llamada anterior a start_transfer o get_state. En este mismo
parmetrodebedevolverlafasequeindicaelsiguientepasodelatransferencia.
Esta operacin se invoca repetidamente sobre el coordinador mientras que la
fasedevueltanoindiqueelfinaldelatransferencia.
Esta operacin no incluye las identidades de los miembros coordinados
cuando, bajo una transferencia concurrente, el mismo coordinador pueda recibir
invocaciones get_state concurrentes. Si la aplicacin necesita transferir diferentes
estados segn sea el miembro destino, puede emplear la fase de coordinacin con
esefin.
7.3.4.set_state
voidset_state(inStates,inPhaseCoordinationphase);
Con este mtodo se establece el estado en el nuevo miembro. El primer
parmetrodefineeseestadoyelsegundo,lafasedecoordinacinasociada.
7.3.5.interrupt_transfer
Se invoca sobre el coordinador y nuevo miembro o miembros cuando la
transferencia se interrumpe por un cambio de vista. En el caso de
MembersOnTransferExcludedFromGroup,noseinvocaenningnmomento.
voidinterrupt_transfer(inoutPhaseCoordinationphase);
Debe devolverse en su nico parmetro una fase que indique el estado del
miembroylatransferencia.Estemismoparmetroseusaparaindicarlaltimafase
dadaporestemiembroenunaoperacinpreviadetransferencia.
La fase devuelta ser empleada ms adelante en la siguiente llamada a
continue_transfer,enelcasodelcoordinador,oasync_transfer,enelcasodelnuevo
miembro.Entreambasllamadas,elmiembrorecibirprobablemente(ydependiendo
del comportamiento ante vistas seleccionado) mensajes del grupo que alterarn su
estado, por lo que esta fase permite al miembro sintetizar los cambios producidos
poresosmensajes.
7.3.6.continue_transfer
Esta operacin se invoca exclusivamente sobre el coordinador, una vez que
una transferencia ha sido interrumpida, envindosele las fases dadas por el
coordinador y el nuevo miembro en la anterior llamada a
interrupt_transfer/sync_transfer. Como ocurre con interrupt_transfer, en el caso de
MembersOnTransferExcludedFromGroup, esta operacin no se invoca en ningn
momento.
voidcontinue_transfer(inLocationsjoining_members,
inoutPhaseCoordinationcoordinator_phase,
inPhaseCoordinationjoining_phase);
Elprimerparmetroincluyelasidentidadesdelosmiembrosacoordinar,pues
puede haber variado con el cambio de vista que produjo la interrupcin de la
transferencia.Elsegundoparmetroincluyelafasequeestemiembrodevolvienla
llamada a interrupt_transfer y, en este parmetro, debe devolver la fase que ser
empleada en las sucesivas llamadas a get_state. Finalmente, el tercer parmetro
incluyelafasedevueltaporelmiembrocoordinadotrasinvocarsync_transfer.
7.3.7.stop_transfer
voidstop_transfer(inLocationsfalling_members,inbooleantransfer_finished);
Cuando se invoca sobre el coordinador, esta operacin da informacin sobre
los miembros excluidos de la transferencia porque hayan cado. Al invocarse, tanto
sobre el coordinador como sobre el nuevo miembro, el segundo parmetro indica
cundo la transferencia ha concluido. En el coordinador, si la transferencia se
considera cancelada en cambios de vistas, este parmetro se recibir siempre con
valortrue.
Al estudiar las condiciones que deben cumplir las aplicaciones y sus
mensajes para realizar la transferencia de estado, comprobamosqueesprecisoque
elGMSinformealaaplicacindelbloqueodevistas;esenesemomentocuandoel
sistema de transferencia de estado realiza las llamadas a interrump_transfer y
desencola los mensajes que han sido enviados durante la vista. Por esa razn, un
sistema puede recibir el evento de interrupcin de vista cuando realmente sta ya
hayafinalizadoporqueelotromiembroenlatransferenciahayacado.Enestecaso,
elmiembrorecibeeleventodeinterrupciny,acontinuacin,eldefinalizacindela
transferencia.
7.4.Propiedadesdemiembros
Al describir el diseo de la interfaz, introdujimos el uso de propiedades sin
entrar en detalle sobre su manejo. Las propiedades no estn ligadas a ningn tipo
en particular y el nico requisito es que se especifican mediante una cadena de
caracteres. En la especificacin CORBA, la interfaz PropertyManager define la forma
deasociarpropiedadesagrupos.
La granularidad en esta interfaz permite especificar propiedades
exclusivamente a nivel de grupo, no sobre los propios miembros. Para las
propiedades que definen el comportamiento del grupo, como sus posibilidades de
concurrencia en las transferencias de estado, esta granularidad es suficiente. Al
discutirlaeleccindelcoordinador,introdujimostambinunanuevapropiedadque
define el peso de cada miembro en una transferencia. Sin embargo, esta propiedad
no es asignable a un grupo, sino a miembros particulares, donde la granularidad
dadaporelPropertyManageresinsuficiente.
Para estos casos de granularidad insuficiente, predefinimos una nueva
propiedadqueasociaacadamiembrounconjuntodepropiedades;sutipoasociado
sedefinecomounasecuenciadepropiedadesparacadamiembroenelgrupo:
structMemberProperties{
Locationmember;
Propertiesprops;
};
typedefsequence<MemberProperties>MemberPropertiesList;
Para la actualizacin dinmica de propiedades, la interfaz PropertyManager
incluye un mtodo para modificar las propiedades de un grupo,
set_properties_dynamically:
interfacePropertyManager{
/*...*/
voidset_properties_dynamically(inObjectGroupobject_group,
inPropertiesoverrides)
raises(ObjectGroupNotFound,InvalidProperty,UnsupportedProperty);
Propertiesget_properties(inObjectGroupobject_group)
raises(ObjectGroupNotFound);
};
Sin embargo, no resultara prctico que un determinado miembro cambiara
una o varias de sus propiedades asociadas mediante este mtodo, pues entonces
deberan especificarse todas las propiedades del grupo. Adems, habra problemas
de concurrencia si varios miembros cambiaran simultneamente sus propias
propiedades.
Estainterfazseextiendeentoncescondosnuevasoperaciones:
interfacePropertyManager{
/*...*/
voidset_member_properties(inObjectGroupobject_group,
inLocationmember,
inPropertiesoverrides)
raises(ObjectGroupNotFound,InvalidProperty,UnsupportedProperty);
Propertiesget_member_properties(inObjectGroupobject_group,
inLocation)
raises(ObjectGroupNotFound);
};
Al emplear pertenencia a grupo controlada por la infraestructura, las
factoras (GenericFactory) reciben las propiedades de cada miembro cuando ste
debesercreado:
interfaceGenericFactory{
Objectcreate_object(inTypeIdtype_id,
inCriteriathe_criteria,
outFactoryCreationIdid);
voiddelete_object(inFactoryCreationIdid);
};
Ennuestrapropuesta,laspropiedadesquedanincluidasenelparmetrodel
tipo Criteria: un miembro recibe sus propias propiedades, las de los dems
miembrosdelgruposeletransfierendurantelatransferenciadeestado.Cuandolas
propiedades cambian dinmicamente, un miembro que implementa la interfaz
PropertiesListenerrecibelanotificacindelcambio.
Definimos a continuacin las propiedades que hemos mencionado en sta y
lasanterioresseccionesparaimplementarlatransferenciadeestado:
conststringCOORDINATOR_WEIGHT=CoordinatorWeight;
conststringMEMBER_PROPERTIES=MemberProperties;
conststringBEHAVIOUR_ON_VIEW_CHANGES=BehaviourOnViewChanges;
constlongMEMBERS_ON_TRANSFER_EXCLUDED_FROM_GROUP=0;
constlongSTATELESS_MEMBERS_DO_NOT_BELONG_TO_GROUP=1;
constlongSTATELESS_MEMBERS_BELONG_TO_GROUP=2;
conststringCONCURRENT_TRANSFERS_ALLOWED=ConcurrentTransfersAllowed;
conststringMULTIPLE_TRANSFERS_ALLOWED=MultipleTransfersAllowed;
conststringUSING_MEMBER_PROPERTIES=UseMemberProperties;
conststringCOORD_ELECTION_APP_CTRL=CoordinatorElectedByApplication;
Las cuatro ltimas propiedades tienen valores booleanos; basta con que se
definan para que se asuma la propiedad asociada. Para el comportamiento en caso
decambiosdevistas,elvalorasociadoesunentero,convaloresyapredefinidos.
7.5.Ejemplosdeuso(usecases)
7.5.1.InterfazCheckpointable
Lafigura7.1muestraelsiguienteescenario,dondeuncambiodevistaprovoca
queelprotocolosereinicie.
Una aplicacin crea un nuevo miembro en un grupo que emplea la interfaz de
transferenciadeestadoCheckpointable.
Seseleccionacomocoordinadoraunodelosmiembrosconestado.
Sesolicitaelestadoalcoordinador.
Se transfiere este estado al nuevo miembro; si se produce un cambio de vista
antesdeenviaresteestado,debereiniciarseelproceso:seleccionarcoordinador,
solicitarleestadoytransferirloalnuevomiembro.
7.5.2.InterfazBasicStateHandler
Mostrar esta interfaz requiere observar su funcionamiento ante diversos
eventos externos. La figura 7.2 muestra un escenario bsico dondenoseproducen
Figura 7.1.InterfazCheckpointable
cambios de vistas. En esta figura, se enva un nico mensaje al grupo durante la
transferencia.
transferenciadeestadoBasicStateHandler.
Seseleccionacomocoordinadoraunodelosmiembrosconestado.
A partir de este momento, se bloquean todos los mensajes al coordinador y al
nuevomiembro,paraserprocesadostrasconcluirlatransferencia.
El coordinador recibe la notificacin de inicio de transferencia, con la
identificacin de los miembros a los que va a realizar esa transferencia. Recibe
tambin una fase sin valor inicial y devuelve una coordinacindefasequeser
usadaenlassiguientesetapas.
Elsistemadetransferenciadeestadoentraenunbucle:
1-Verificaconesacoordinacindefasesilatransferenciahafinalizado.
2- Solicita al coordinador el estado, pasndole la coordinacin de fase que ha
devueltoenelpasoanterioryesperandounanuevacoordinacindefaseparala
siguienteetapa.
3-Setransfiereelestadoylacoordinacindevueltasalnuevomiembroonuevos
miembros.
Al concluir la transferencia, el sistema comunica al coordinador y al nuevo o
nuevosmiembrosquelatransferenciahaconcluido.
Figura7.2.InterfazBasicStateHandler sincambiosdevistas
Losmensajesencoladosdurantelavistaseenvanparasuprocesamientoporel
coordinador y nuevo o nuevos miembros. Si el coordinador tuviera ms
miembrosquecoordinar,nopodrtodavaprocesaresosmensajes,queseguiran
encolados.
El escenario se complica si se producen cambios de vistas. La figura 7.3
muestra un cambio de vista en un grupo en modo
MembersOnTransferExcludedFromGroup, donde los miembros involucrados en la
transferencia no se ven afectados por cambios de vistas; la figura 7.4 incluye el
mismoescenario,enelcasoenqueelcoordinadorsecae.
Eliniciosiguelamismapautaqueenelprevioescenariopero,antesdeconcluir
la transferencia, se produce un cambio de vista. Si el coordinador se cae, los
nuevos miembros reciben la notificacin de parada de transferencia y,
eventualmente, sta se reiniciar con otro coordinador. Si uno o ms de los
miembros coordinados se cae, el coordinador recibe una notificacin de parada
detransferenciasobreesosmiembrosy,sitodoslosmiembroshubierancado,el
parmetrofinished_transfertendraunvalortrue.
El coordinador mantiene los mensajes encolados hasta el momento en una
segunda cola, ya que debe conocer en todo momento los mensajes encolados
provenientesdelavistaactualodevistasanteriores.
Latransferenciacontinaconlospasosanteriores.
nuevosmiembrosquelatransferenciahaconcluido.
Figura 7.3.InterfazBasicStateHandler, MembersOnTransferExcludedFromGroup
Los mensajes encolados por los nuevos miembros durante las vistas que ha
durado la transferencia son desbloqueados y procesados. El coordinador
solamentepuedeprocesarlosmensajesencoladosenvistasanteriores.Losdela
vista actual slo los podr procesar si notienependienteningunatransferencia
deestadoaotromiembro.
Falta en estos escenarios mostrar un caso en que el coordinador debe iniciar
una segunda transferencia en la misma vista en que concluye una transferencia
previa. Porsusemejanzaconotrosejemplos,esecasosemuestramsadelante,en
la figura 7.6. Primero observamos un ejemplo en el que los cambios de vista
provocanunacancelacindelatransferencia:
transferenciadeestadoBasicStateHandleryespecificacomopropiedaddelgrupo
que el comportamiento ante cambios de vistas es cancelar la transferencia:
StatelessMembersDoNotBelongToGroup. Es posible emplear tambin
StatelessMembersBelongToGroup, pero la utilidad de esta aproximacin es poco
clarasilosmiembrosnopuedencontinuarunatransferenciacancelada.
Los pasos de seleccin del coordinador y el bucle de obtencin del estado y su
transferencia al nuevo miembro son idnticos a los ejemplosanteriores,puesel
comportamientoslodifiereanteuncambiodevista.
Se produce un cambio de vista. El sistema comunica al coordinador y nuevo o
nuevos miembros que la transferencia se para, sin haber concluido. Los
mensajes encolados en el coordinador son desbloqueados, este miembro slo
Figura 7.4.InterfazBasicStateHandler, MembersOnTransferExcludedFromGroup
concada del coordinador.
recibir el evento de nueva vista tras haber procesado esos mensajes. El nuevo
miembro,sinembargo,descartaesosmensajesencolados.
Sinosehacadoelnuevomiembro,latransferenciadebecontinuar,porloque
el sistema la reiniciar, usando el mismo coordinador. Si se hubiera cado, se
selecciona directamente un nuevo coordinador, sin informar al nuevo miembro.
El coordinador recibe la notificacin de inicio de transferencia y los pasos
anterioresserepitenenelmismoorden.
nuevosmiembrosquelatransferenciahafinalizado.
Losmensajesencoladosdurantelaltimavistaseenvanparasuprocesamiento
por el coordinador y nuevo o nuevos miembros. Si el coordinador tuviera ms
transferenciasporrealizar,nopodrtodavaprocesaresosmensajes.
Este escenario se muestra en la figura 7.5, aunque los pasos en la segunda
vista se han obviado. Para ver el ltimo paso de este escenario, en el que el
coordinador no puede procesar los mensajes bloqueados hasta finalizar la nueva
transferenciaenmarcha,empleamoselsiguienteescenario,quereflejalafigura7.6:
Eliniciodelescenarioserealizacomoenelcasoanteriory,antesdefinalizarla
transferencia,unanuevavistaseinstalaparainsertarunnuevomiembro,alque
seleasignaelmismocoordinador.Latransferenciaenmarchasepara.
Tras instalarse la vista, se reinicia la transferencia entre el coordinador y el
anterior miembro. Los mensajes en el grupo estn bloqueados para los dos
Figura 7.5.InterfazBasicStateHandler, StateMembersBelongToGroup
miembros de la transferencia, as como para el nuevo miembro, que an no ha
iniciadoningunatransferencia.
La primera transferencia de estado termina; el miembro que ha adquirido el
estado puede procesar los mensajes enviados en esta vista, mientras que el
coordinador debe, todava, finalizar la segunda transferencia antes de poderlos
procesar.
7.5.3.InterfazStateHandler
Para mostrar esta interfaz, empleamos dos casos, con y sin cada del
coordinador. Usamos como modos del grupo StatelessMembersDoNotBelongToGroup
y StatelessMembersBelongToGroup, ya que no es necesario un ejemplo con
MembersOnTransferExcludedFromGroup, pues en este modo la interfaz se usa slo
mnimamente, al no invocarse las operaciones continue_transfer o interrupt_transfer.
En ambos ejemplos, se omiten los mensajes get_state y set_state que se realizan
durantelatransferencia.
La figura 7.7 muestra un escenario donde los nuevos miembros no se
consideranmiembrosdelgrupo:
transferencia de estado StateHandler y especifica como propiedad del grupo
StatelessMembersDoNotBelongToGroup.
Figura 7.6.InterfazBasicStateHandler, StateMembersBelongToGroup
con sucesivascoordinaciones.
El escenario contiene tres miembros con estado y un nuevo miembro, an sin
estado consistente. Se selecciona como coordinador uno de los miembros con
estado.
El primer paso de la transferencia es consultar al nuevo miembro mediante
sync_transfersobrelafasequeesperainicialmente.
Se transfiere esta fase al coordinador, que inicia entonces la transferencia,
mediante los mensajes get_state, set_state que no se muestran en la figura. Los
miembrosinvolucradosenlatransferencianorecibenlosmensajesdelgrupo;el
escenario muestra un mensaje A que es recibido exclusivamente por los dos
miembrosconestadonoinvolucradosenlatransferencia.
Se produce un cambio de vista por la cada de un miembro con estado. El
sistematransfiereelbloqueodevistaalosmiembrosycomunicaalcoordinador
y nuevo o nuevos miembros que la transferencia se interrumpe. Los mensajes
encolados en el coordinador son desbloqueados, este miembro slo recibir el
evento de nueva vista tras haber procesado esos mensajes. El nuevo miembro,
sinembargo,descartaesosmensajesencolados.
Tras instalarse la nueva vista, la transferencia se reinicia. El nuevo miembro
recibe,denuevo,unasolicituddesincronizacindelatransferencia,queincluye,
ahora,lafasequedevolviduranteinterrupt_transfer.
El coordinador recibe unapeticincontinue_transfer,conlafasequedevolvien
interrupt_transfer y la dada por el nuevo miembro en sync_transfer. La opcin
Figura7.7.InterfazStateHandler,StateMembersDoNotBelongToGroup
sincada del coordinador
segura por defecto es reiniciar la transferencia, pero el intercambio de
informacinpuedepermitiraunaaplicacinalterarestecomportamiento.
Cuando la transferencia concluye, se enva a los miembros que la realizaron
cualquier mensaje encolado. Estos mensajes encolados slo pueden provenirde
la vista actual. Como en los ejemplos anteriores, si el coordinador tuviera ms
transferenciasporrealizar,nopodratodavaprocesaresosmensajes.
La figura 7.8 muestra un escenario parecido donde los nuevos miembros se
consideranpartedelgrupoansinestado:
Los pasos iniciales se realizan como en el casoanterior,peroelgruposedefine
conpropiedadStatelessMembersBelongToGroup.
Elcoordinadorsecaeantesdeconcluirlatransferencia;elGMSenvaunevento
debloqueodevista.
Al bloquearse la vista, la transferencia se para, por lo que el nico miembro
sobrevivientedelatransferenciarecibeuneventointerrupt_transfer.
Losmensajesbloqueadosseenvanalnuevomiembro,queseconsiderapartedel
grupo.
Al instalarse la vista, el sistema de transferencia de estado detecta la cada del
coordinador, por lo que invoca stop_transfer sobre el nuevo miembro, antes de
comunicarlelanuevavista.
Se selecciona un nuevo coordinador, y se reinicia la transferencia invocando
primerosync_transfersobreelnuevomiembro.
Figura 7.8.InterfazStateHandler, StateMembersNotBelongToGroup
concada del coordinador
Elnuevocoordinadorrecibeeleventostart_transferysereiniciantodoslospasos
previos.
7.6.Implementacinsobreprotocolosdebajonivel
El anterior captulo mostr los protocolos de bajo nivel y sus beneficios
relativos, y este captulo, al desarrollar el protocolo de alto nivel, no ha mostrado
ningnnfasissobreelprotocolosubyacente.Elmotivoesquelosprotocolospully
pushsediferenciannicamenteenlaeleccininicialdelcoordinador,porloqueen
lneas generales, el comportamiento es idntico y la nica excepcin es,
precisamente,lainterfazdealtoniveldeeleccindelcoordinador,quepuedeserno
deterministaenelcasopull.
Mostrar la implementacin detallada de los protocolos implicara una larga
lista de condicionales, teniendo en cuenta los tres modos de comportamiento del
grupo y las tres posibles interfaces a implementar. Como, adems, la conversin
entre los mensajes del protocolo de bajo nivel y las operaciones en la interfaz de
aplicacin es prcticamente directa, nos limitamos a mostrar dos escenarios que
muestranestaconversin,usandoprotocolopush.
La figura 7.9 muestra un escenario comn, vlido para las interfaces
BasicStateHandler y StateHandler, sin cambios de vistas durante la transferencia.
En este caso, los tres modos de comportamiento generan las mismas operaciones.
Cuando se producen cambios de vistas, el comportamiento es ya totalmente
Figura 7.9.Implementacinsobreprotocolo push sin cambios devistas
diferente y las operaciones difieren completamente si se emplea la interfaz
BasicStateHandler, donde la transferencia queda cancelada, o la interfaz
StateHandler, donde se considera interrumpida; sin embargo, en ambos casos, los
mensajes subyacentes son los mismos. La figura 7.10 muestra el cambio de
mensajesylasoperacionesduranteuncambiodevistaparalainterfazStateHandler
cuandonoseempleamodoMembersOnTransferExcludedFromGroup.
El anterior captulo desarroll un protocolo ms, denominado push-one step,
donde el estado se transfiere en un nico mensaje multipunto. Empleando este
protocolo de bajo nivel, no es posible, evidentemente, implementar ninguna de las
interfacesmsavanzadas,ylaaplicacinestlimitadaalainterfazCheckpointable.
7.7.Conclusiones
Con la interfaz de aplicacin desarrollada, es posible implementar una
transferencia de estado considerablemente compleja, al habilitarse un canal de
comunicacinbidireccionalentrelaspartesqueparticipandeesatransferencia.
Aunque tericamente las transferencias de estado no bsicas deberan
cancelarse ante cada cambio de vista, las necesidades de una aplicacin especfica
pueden hacer obviar este requisito, a costa de no respetar escrupulosamente el
modelo de sincrona virtual: si la aplicacin se programa con esa premisa, esta
violacindelmodelopuederealizarsesinningunarepercusinnegativa.
Figura 7.10.Implementacinsobreprotocolo push con cambios devistas
Adems de este soporte de transferencias interrumpidas y transferencias en
varios pasos, la interfaz soporta concurrencia en la transferencia, empleo de
propiedades de miembros y diferentes posibilidades en la eleccin del coordinador.
Y, pese a la complejidad de la interfaz, sta se ha definido de tal forma que
aplicacionesqueprecisantransferenciassimplesnodebanimplementaroperaciones
complejas.
Por ltimo, la interfaz ha quedado definido en JavaRMI y en OMG/IDL, y su
especificacin se ha realizado maximizando su compatibilidad con la actual
especificacindetoleranciaafallosdeCORBA.Basndonosenestainterfaz,hemos
realizado,asimismo,suimplementacinsobreSensei,elsistemadecomunicaciones
en grupo que hemos desarrollado especficamente en este proyecto. Esta
implementacinsedetallaenelcaptulo10.
SenseiGMS 115
Captulo8-SENSEIGMS
SenseiGMS es un sistema de grupo de comunicaciones fiables desarrollado
especficamente paraesteproyecto.Estbasadoenelmodelodesincronavirtualy
sobre este sistema se han implementado los protocolos de transferencia de estado
presentadosenlosanteriorescaptulos,ascomovariastcnicasdesarrolladaspara
lasimplificacindesistemasfiables,descritasenlossiguientescaptulos.
Sudiseoseharealizadobajotresrequisitos:
Soportar una funcionalidad simple y bsica para facilitar su implementacin,
pues el objetivo de este proyecto no es el desarrollo de un sistema de
comunicaciones fiables de grupo, sino la implementacin de los protocolos de
transferencia de estado estudiados y de herramientas que simplifiquen el
desarrollodeaplicacionesreplicadas.
Limitar su funcionalidad a la descrita en el modelo de sincrona virtual,
permitiendo nicamente las extensiones disponibles en otros sistemas de
comunicaciones ampliamente conocidos, como es el envo de mensajes punto a
punto. El objetivo de este requisito es poder sustituir este sistema por esos
sistemas de comunicaciones existentes, generalmente ms complicados
funcionalmenteyconmejorrendimiento.
Presentar una interfaz orientada a objetos y con soporte de mensajes tipados,
conelobjetivodefacilitareldesarrollodelascapassituadassobreestesustrato
decomunicaciones.
SenseiGMS 116
Este captulo presenta el diseo de SenseiGMS y los algoritmos que lo
sustentan, as como el modelo de programacin que soporta. Las razones que han
impuesto la creacindeunsistemapropiodecomunicacionesengruposereducen
bsicamentealanecesidaddedisponerdeunsistemasobreCORBAyJavaRMI;en
elmomentodedesarrollarlamayorpartedelatesis,nohabadisponibilidaddeun
sistemadecomunicacionesengruposobreCORBA,apesardequelaespecificacin
detoleranciaafallosdeestaarquitecturaestuvierayaaceptada.Delamismaforma,
la necesidad de desarrollar nuestro propio algoritmo para las comunicaciones
multipunto fiables se justifica al observar que los algoritmos existentes se basan
normalmente en el empleo de primitivas de comunicaciones multipunto no fiables
(UDP), cuando la especificacin de nuestro sistema incluye slo soporte de
comunicacionesfiablespuntoapunto.
8.1.Diseo
SenseiGMSsoportaaplicacionesCORBAyJavaRMI.Suinterfazestorientada
aobjetos,especificadadirectamenteenOMG/IDLyenJava,ycomolasaplicaciones
deben definir sus mensajes de la misma forma, el soporte de mensajes tipados es
directo.
LainterfazdeaplicacindeSenseiGMSestbasadaenladefinidaenIsisque,
a su vez, ha sido la base para un gran nmero de sistemas de comunicaciones en
grupo:Horus,Ensemble,Totem,TransisoJavaGroups.
Las comunicaciones se realizan directamente empleando CORBA o JavaRMI.
Laaproximacinempleadaenotrossistemasdecomunicacionesescrearlaspilasde
protocolos sobre UDP o, incluso, directamente sobre IP, pilas que adems resultan
dinmicasenlaseleccindelosalgoritmosdeordenacindemensajes.Estaeleccin
implica un peor rendimiento en SenseiGMS, pero simplifica su diseo.
Adicionalmente, la eleccin de un middleware de alto nivel como substrato de
comunicaciones permite emplear las facilidades y servicios asociados al mismo.Por
ejemplo, empleando applets autentificados, se podran desarrollar applets tolerantes
afallosmsfcilmentequesielsoporteserealizadirectamentesobresockets.Dela
misma manera, se pueden aprovechar otras facilidades como http tunneling, ya
disponiblesaltrabajarconJavaRMIoCORBA,oladescargadinmicadecdigo.
Otra de las decisiones de simplificacin del diseo es el soporte exclusivo de
orden total causal en la secuenciacin de mensajes. El algoritmo empleado para
obtenerelordentotalcausal,esmedianteelpasodeuntestigosobreunanillolgico
compuesto porloscomponentesdelgrupo,quepuedecambiarsuestructurasegn
seincluyannuevosmiembrosenelgrupooantiguosseanexcluidos.Ladecisinde
soportarexclusivamenteordentotalestinfluenciada,adems,portresmotivos:
La programacin de aplicaciones replicadas se simplifica enormemente cuando
losmensajesseprocesanenordentotal.
SenseiGMS 117
Elprotocoloquesustentaelordentotalpuedesoportaresteordenauncosteno
mayorqueconempleodeordencausalosimplementeconmensajesfifopuntoa
puntofiables[Amir95].
LaespecificacindelserviciodetoleranciaafallosdeCORBAincluyenicamente
elsoportedeesteordendesecuenciacin.
Para soportar simultneamente ambas plataformas, SenseiGMS define su
interfaz en OMG/IDL o en JavaRMI, e implementa separadamente los algoritmos,
comunes en los dos casos, empleando Java. Desde el punto de vista de
implementacin, tanto la interfaz OMG/IDL, como la interfaz JavaRMI, comparten
un mismo package, llamado sensei.middleware.GMS, aunque se localizan en
distintos directorios. Los algoritmos comunes, definidos en el paquete sensei.GMS,
se compilan sobre una de las plataformas previas, simplemente seleccionando un
classpath diferente. El nico requisito, en este caso, es que ambas interfaces sean
completamentecompatibles.
La interfaz que SenseiGMS presentaalaaplicacin,queincluye,porejemplo,
operaciones para el envo de mensajes fiables, constituye su interfaz pblica. Sin
embargo, para realizar las comunicaciones internas tambin en CORBA o JavaRMI,
como, por ejemplo, el paso del testigo entre miembros de un grupo, es necesario
definirunasegundainterfazenloscorrespondienteslenguajes.Estaltimainterfaz
es privada; en caso de querer sustituir SenseiGMS por otro grupo de
comunicaciones,esnecesariosoportarexclusivamentelainterfazpblica.
Finalmente, SenseiGMS no presenta ningn soporte de transferencia de
estado.Apesardelnfasisdeestatesisenlosalgoritmosdetransferenciadeestado,
esta decisin permite implementarlos totalmente en una capa superior, soportando
asmsfcilmentesumigracinaotrossistemasdecomunicacionesengrupo.
8.1.1.Interfazpblica
Estainterfazsebasaentrestiposbsicos:
Identidadesdemiembros,paraloqueseempleaunsimpleentero,quedebeser
nicoparacadamiembrodelgrupo.
Definicindemensajes.Cadaaplicacinpuededefinirsuspropiosmensajes,que
deben pertenecer a una jerarqua de objetos definida. Estos mensajes pueden
definirseendetalleobtenindose,as,mensajestipados.
Definicin de vistas, acorde al modelo de sincrona virtual. Cuando un grupo
cambia su composicin, cada miembro del grupo recibe una lista con todos los
miembros. Esta lista constituye la vista que incluye, asimismo, una identidad
quesedefinedeformanumrica.
EnOMG/IDL,suespecificacines:
SenseiGMS 118
typedeflongGroupMemberId;
typedefsequence<GroupMemberId>GroupMemberIdList;
structView
{
longviewId;
GroupMemberIdListmembers;
GroupMemberIdListnewMembers;
GroupMemberIdListexpulsedMembers;
};
valuetypeMessage{};
EnSenseiGMS,porconveniencia,lasvistasincluyentambinunalistaconlos
miembrosexcluidosylosnuevosmiembrosenelgrupo.Esimportantedestacarque
esta informacin no supone una funcionalidad aadida: un miembro nuevo recibe
una vista en la que todos los dems miembros son listados como nuevos. Este
detalle es importante para los algoritmos de transferencia de estado, que pueden
simplificarse si las vistas contienen informacin con la que discernir cundo un
miembro es ms antiguo que otro. Siguiendo el objetivo de no ofrecer mayor
funcionalidadqueotrossistemasdecomunicaciones,estainformacinnoseincluye.
La definicin de mensaje como valuetype es esencial. Si se define como
interface,elmensajenoesrealmentetransferidoacadamiembrodelgrupo,queslo
recibeunareferenciaremota;sisedefinecomostruct,setransfiereacadamiembro
delgrupo,peronosepuedendefinirnuevosmensajesporherencia.
Bajo JavaRMI, la especificacin resulta similar; sin incluir los constructores
paralaclase,es:
finalpublicclassViewimplementsjava.io.Serializable
{
publicintviewId;
publicint[]members;
publicint[]newMembers;
publicint[]expulsedMembers;
}
publicabstractclassMessage
implementsjava.io.Serializable
{
}
Un objeto debe implementar la interfaz GroupMember para poderpertenecera

ungrupo.EstainterfazseespecificaenJavaRMIcomo:
SenseiGMS 119
publicinterfaceGroupMemberextendsjava.rmi.Remote
{
publicvoidprocessPTPMessage(intsender,Messagemessage)throwsRemoteException
2
;
publicvoidprocessCastMessage(intsender,Messagemessage)throwsRemoteException;
publicvoidmemberAccepted(intidentity,GroupHandlerhandler,Viewview)
throwsRemoteException;
publicvoidchangingView()throwsRemoteException;
publicvoidinstallView(Viewview)throwsRemoteException;
publicvoidexcludedFromGroup()throwsRemoteException;
}
Atravsdeestainterfaz,elmiembrorecibetodaslascomunicacionesdelgrupo
que,siguiendoelordenmostrado,es:
Recepcindemensajesmultipunto:todoslosmiembrosvenlamismasecuencia
demensajes.Elmiembroqueenvaunmensajetambinlorecibe.
Recepcin de mensajes punto a punto. SenseiGMS respeta el orden total tanto
entre mensajes multipunto como entre mensajes punto a punto; sin embargo,
stanoesunacaractersticacomnaotrossistemasdecomunicacionesfiables,
donde estos mensajes pueden recibirse con antelacin a mensajes multipunto
que les preceden en el orden establecido. Por esta razn, ninguno de los
algoritmosenSenseiesdependientedeesteordenenmensajespuntoapunto.
Aceptacin del miembro en el grupo, que es el primer evento que se recibe en
todosloscasos.
Eventodecambiosdevista.Serecibeantesdequeseinstaleunanuevavista,e
implicaqueelserviciodepertenenciademiembroshadetectadoqueesnecesario
un cambio de vista y est negociando la nueva composicin del grupo. Este
evento no se incluye en el modelo de sincrona virtual, pero es comn en los
sistemasdecomunicacionesengrupo.Losprotocolosdetransferenciadeestado
precisanesteevento,comosedemostrenloscaptulosanteriores.
Instalacindeunanuevavista.
Eventodeexclusindelgrupo,yaseaporpeticindelmiembro,oporqueelGMS
considere,errneamente,queestemiembrohacado.
Un miembro interacta con los dems miembros del grupo a travs de la
interfaz GroupHandler, que define la interfaz pblica del servicio de pertenencia a
grupos o GMS. Esta interfaz no define cmo crear el grupo o cmo incluir un
miembro en un grupo ya existente, pues esta funcionalidad es especfica a la
implementacin de SenseiGMS y se define como parte de su interfaz privada. Hay
una relacin biunvoca entreGroupMemberyGroupHandler,esdecir,cadamiembro
2
Todaslasexcepcionessonjava.rmi.RemoteException.
SenseiGMS 120
del grupo mantiene una instancia del servicio de pertenencia a grupos. Otros
sistemas de comunicaciones engrupopermiten,sinembargo,queunainstanciade
este servicio controle varios miembros o, incluso, varios grupos, pero esta
aproximacinnoimplicaunamayoromenorfuncionalidadenningncaso.
EstainterfazseespecificaenJavaRMIcomo:
publicinterfaceGroupHandlerextendsjava.rmi.Remote
{
publicbooleancastMessage(Messagemessage)throwsRemoteException;
publicbooleansendMessage(inttarget,Messagemessage)throwsRemoteException;
publicbooleanleaveGroup()throwsRemoteException;
publicintgetGroupMemberId()throwsRemoteException;
publicbooleanisValidGroup()throwsRemoteException;
}
Lasoperacionesdefinidasson:
Enviarunmensajealgrupo,queesrecibidoportodoslosmiembros,incluidoel
que lo enva. Devuelve un valor que indica si el mensaje ser procesado en la
vista actual. A partir del momento en que el servicio de pertenencia al grupo
bloqueaunavistaparanegociarlacomposicindelasiguiente,todoslosnuevos
mensajes que se enven en el gruposonbloqueados,siendosloenviadosenla
siguientevista.
Enviar un mensaje a un miembro determinado del grupo. Para mantener una
interfazcoherente,estaoperacindevuelveunvalortruesielmensajeesrecibido
porelmiembrodestinatarioenlamismavista.
Abandonar el grupo. Esta operacin no es inmediata, el miembro no es
efectivamenteexpulsadohastarecibireleventodeexpulsin.
Detectarsiungrupoesvlido.
Obtenerlaidentidaddemiembroasociada.
LaespecificacinenOMG/IDLdeestostiposesparalela:
interfaceGroupMember
{
voidprocessPTPMessage(inGroupMemberIdsender,inMessagemsg);
voidprocessCastMessage(inGroupMemberIdsender,inMessagemsg);
voidmemberAccepted(inGroupMemberIdidentity,inGroupHandlerhandler,
inViewtheView);
voidchangingView();
voidinstallView(inViewtheView);
voidexcludedFromGroup();
};
SenseiGMS 121
interfaceGroupHandler
{
booleancastMessage(inMessagemsg);
booleansendMessage(inGroupMemberIdtarget,inMessagemsg);
booleanleaveGroup();
GroupMemberIdgetGroupMemberId();
booleanisValidGroup();
};
8.1.2.Interfazprivada
La parte privada de la interfaz define las operaciones que los miembros del
GMS deben soportar para implementar su propio protocolo de comunicaciones, en
estecaso,basadoenelpasodeuntestigo.Ladefinicinprincipalesladelmiembro
del GMS, denominada SenseiGMSMember, que es una extensin de la definicin de
GroupHandler presentada en la seccin anterior. En esta seccin, los tipos estn
especificados empleando nicamente OMG/IDL pues, como se ve en los casos
anteriores,laespecificacinJavaRMIesinmediata.
Las operaciones definidas en esta interfaz estn fuertemente ligadas a los
algoritmos empleados para mantener el modelo de sincrona virtual. Dos
caractersticas importantes, desarrolladas en mayor profundidad al explicar el
protocolo,son:
Cadamiembropuedecomunicarseconlosotroscuandoposeeeltestigo.Comoel
principal problema en este tipo de comunicacin es que el testigo aparezca
duplicadoenelgrupo,sedefinedetalformaqueseaidentificablesinposibilidad
deduplicados.Empleamossuanglicismo,token,paranombrarlo:
structToken
{
GroupMemberIdcreator;
longid;
};
En la interfaz pblica, los miembros reciben vistas con lasidentidadesdetodos
los miembros del grupo. Sin embargo, para realizar las comunicaciones, es
necesario que se conozcan las referencias a estos miembros, no slo sus
identidades,loquesuponeelempleodevistasinternas.Adicionalmente,existeel
concepto de vista temporal, como cada una de las vistas que el grupo negocia
mientras se discute la composicin final del grupo; por esta razn, la identidad
devistainternaincluyeuncampoidentificandolavistacomotemporal:
structInternalViewId
{
longid;
SenseiGMS 122
longinstalling;
};
typedefsequence<SenseiGMSMember>SenseiGMSMemberList;
structInternalView
{
InternalViewIdviewId;
SenseiGMSMemberListmembers;
GroupMemberIdListmemberIds;
};
LainterfazSenseiGMSMembersedefinecomo:
interfaceSenseiGMSMember:GroupHandler
{
booleanreceiveToken(inGroupMemberIdsender,inTokentheToken);
booleanreceiveView(inGroupMemberIdsender,inInternalViewview,
inTokenviewToken);
booleanreceiveMessages(inGroupMemberIdsender,inMessageListmessages,
inMessageIdmsgId);
booleanconfirmMessages(inGroupMemberIdsender,inMessageIdmsgId);
booleanreceivePTPMessages(inGroupMemberIdsender,inMessageListmessages,
inMessageIdmsgId);
AllowTokenRecoveryAnswerallowTokenRecovery(inGroupMemberIdsender,
inInternalViewIdmyViewId);
booleanrecoverToken(inGroupMemberIdsender);
booleanaddGroupMember(inSenseiGMSMemberother);
booleancreateGroup();
booleanjoinGroup(inSenseiGMSMembergroup);
};
Estas operaciones se describen junto a su significado en la siguienteseccin,
alexplicarelalgoritmoempleado.Lastresltimasoperacionessonlasquepermiten
crear o extender grupos, tomando como argumento una referencia a un objeto del
mismo tipo. Es decir, slo un miembro que implemente esta interfaz privada puede
incluirse en el grupo y, por esa razn, es preciso definir estas operaciones como
privadas.
Para que una aplicacin pueda crear rplicas sin necesidad de acceder a esta
interfaz privada, Sensei incluye una interfaz externa denominada SenseiGMNS que
contempla la funcionalidad generalmente disponible en otros sistemas de
pertenencia a grupo. GMNS significa GroupMembershipNamingService pues, adems
de incluir la creacin y extensin manual de grupos, permite manejarlos de forma
simple, asociando un nombre a los grupos. Este servicio, totalmente ligado a la
implementacindeSenseiGMS,sedescribeenelcaptulo11.
SenseiGMS 123
Todas las operaciones devuelven un valor booleano; si ste es false, implica
que el miembro destino no acepta la operacin efectuada, generalmente porque
considerealmiembrofuentenopertenecientealgrupo.Laexcepcineslaoperacin
allowTokenRecovery,queprecisamsinformacinysedefinecomo:
structAllowTokenRecoveryAnswer
{
booleanvalidCommunication;
booleanrecoveryAllowed;
MessageIdlastMessage;
};
8.2.Algoritmodepasodetestigo
SenseiGMSsebasaenelpasodeuntestigoquecirculaentrelosmiembrosdel
grupo; la posesin del testigo permite realizar el ordenado de los mensajes de una
formasencilla,yelalgoritmoquedaslocomplicadoporlanecesidadderegenerarel
testigo si el miembro que lo controlaba se cae, e impedir a la vez que dos testigos
circulensimultneamenteenelgrupo.
Casi todas las operaciones de grupo que un miembro puede realizar, tales
como enviar mensajes, expulsar a miembros sospechosos de haber cado o incluir
nuevos miembros, se realizan, exclusivamente, una vez que el miembro entra en
posesindeltestigo.Lanicaexcepcinserefierealasoperacionesderecuperacin
deltestigo.
El paso de un testigo no es la nica forma de obtener orden total. En Ameba
[Kaashoek91], por ejemplo, el orden total se alcanza mediante un proceso especial,
denominado secuenciador, al que losdemsprocesosenvansusmensajespuntoa
punto; el secuenciador los redistribuye luego a los dems miembros con el orden
adecuado. El protocolo Psync [Peterson89] crea un orden parcial en los mensajes
quepuedeserconvertidoenordentotal.
Sin embargo, son ms numerosos los sistemas basados en paso de testigo.
Totem define un algoritmo muy eficiente de paso de testigo que admite, adems, el
particionadodelared.AligualqueenSenseiGMS,elmiembroqueposeeeltestigo
es el nico que enva mensajes aunque, en otros casos [Chang84], cualquier
miembro puede enviar mensajes en cualquier momento, produciendo, sin embargo,
altas latencias cuando hay numerosos mensajes en el grupo o ante cadas de
miembros. Similar al protocolo de Totem es el protocolo TPM [Rajagopalan89],
aunque no admite el particionado de los grupos. Estos protocolos se basan en el
soporte de mensajes multicast best-effort, principalmente UDP, mientras que
SenseiGMSseconstruyesobrelascomunicacionespuntoapuntodeCORBAoRMI,
loquehaprovocadolanecesidaddedesarrollarunalgoritmopropio.
SenseiGMS 124
8.2.1.Pasodetestigoyestructuraenanillo
Los miembros pueden considerarse lgicamente dispuestosenunaestructura
deanillo,dondelavistadefineloscomponentesysurespectivoorden.Esteanilloes
dinmico, expandindose segn nuevos miembros se insertan en el grupo o los
antiguos lo abandonan o son excluidos. La implementacin actual del algoritmo
insertalosmiembroslgicamentetraselmiembroquelosintroduceenelgrupo.
Untestigonoes,enrealidad,masqueuntipoespecialdemensajetransferido
puntoapunto.Cuandounanuevavistatemporalsecrea,sedefineunnuevotestigo
con una identidad nica, que el miembro que enva la vista propaga junto con esa
vista.Estetestigocircula,acontinuacin,enelgrupoylosmiembrosdebenverificar
su identidad. Dos problemas pueden aparecer con este paso de testigo. El primer
problema es que el miembro que posee el testigo se caiga, con lo que el testigo se
pierde. Todos los miembros disponen de un temporizador que se reinicia cada vez
queelmiembrorecibeunacomunicacin.Sieltemporizadorvence,elmiembrotrata
deregenerareltestigo,segnsedetallaenelapartadoposteriorderecuperacindel
testigo. El segundo problema viene asociado a ste y consiste en que el miembro
considerado cado fuera simplemente muy lento y otro genere un nuevo testigo,
terminando el grupo con varios testigos activos. Este punto se soluciona con que
cada miembro admita slo un testigo como vlido, con lo que no esposiblequeun
mismomiembrotransmitadosomstestigosdiferentes.Estasolucinconllevaque
el grupo puede particionarse, pero no se compromete la integridad de sus
comunicaciones.
Este paso de testigo, realizado a travs de la operacin receiveToken, implica
que el grupo est realizando comunicaciones continuamente, incluso cuando la
aplicacin est inactiva sin enviar mensajes. El sistema puede detectar esta
inactividad y retrasar el envo del testigo entre miembros en estos casos. En
cualquiercaso,otrossistemasnobasadosenpasodetestigodebenrealizartambin
comunicacionesperidicasparadetectarcadasdemiembros.
8.2.2.Deteccindeerrores
La deteccin de errores se realiza a partir de las comunicaciones normales:
envodemensajesyvistas,pasodetestigo,etc.Siunmiembronopuedeaccedera
otro, lo considera cado. Adicionalmente, el miembro contactado debe responder en
untiempolmite,configurablesegnsealacalidaddelared.
Puesto que el paso del testigo se realizacontinuamente,lacadadelmiembro
se detectar de forma razonablemente rpida, salvo que el miembro que posee el
testigoseaelquesehayacado.Porestarazn,todomiembroesperarecibiralguna
comunicacindelgrupoenuntiempodadoysinoseproduce,iniciaelprotocolode
regeneracindeltestigo.
SenseiGMS 125
Problemasenlaredomiembroslentospuedensuponerdeteccionesdeerrores
errneas. Sin embargo, una vez que un miembro considera a otro errneo tal
decisinespermanente,ylocomunicaalosdemsmiembrosdelgrupoquepasana
considerarlo errneo igualmente. En estas condiciones, rechazan cualquier
comunicacinprovenientedeestemiembrofalsamenteerrneo.
A la inversa, si un miembro accede a otro y este ltimo rechaza la
comunicacin, el primero le considera errneo igualmente y se lo comunica a los
dems.Estasituacinpuedesuponerladivisindelgrupo,peroslouno,oincluso
ninguno, de los nuevos grupos tendr consenso y sobrevivir, puesto que
SenseiGMS no soporta particionados de la red. Los sistemas de sincrona virtual
extendida permiten que varios subgrupos permanezcan activos tras su divisin por
problemas de comunicaciones en la red; si esta funcionalidad no se soporta, debe
asegurarse que slo uno de los grupos, como mximo, permanezca activo. Este
objetivoselograimponiendounrequisitosobrelasvistas:unavistatemporalslose
acepta si contiene, al menos, la mayora de los miembros que se incluan en la
anterior vista permanente. Esta implementacin implica que un grupo de dos
miembros donde uno realmente cae, perder el consenso y se volver inoperativo;
por esta razn, SenseiGMS permite definir grupos como pertenecientes a una red
fiable,relajando,enestecaso,elanteriorrequisitoypermitiendoqueelconsensose
mantenga convistasconteniendoslolamitaddelosmiembrosdelaanteriorvista
permanente.Enestoscasos,decimosqueSenseiGMStrabajaconconsensodbil.
8.2.3.Envodemensajes
El modelo de sincrona virtual no prescribe el soporte de mensajes punto a
punto entre los miembros de un grupo; su soporte bajo un algoritmo de paso de
testigoessinembargosencillo,inclusorespetandoelordenentremensajespuntoa
punto y mensajes al grupo. Es adems importante:aunquebajoCORBAoJavaRMI
cada componente puede realizar comunicaciones punto a punto con otros
componentes, lainformacinincluidaenlavistanocontienelasreferenciasaotros
miembros, sino sus identidades, una abstraccin que slo tiene significado bajo
SenseiGMS.
Unmiembroencolatodoslosmensajesaenviar,queprocesacuandorecibeel
testigo. Bajo condiciones normales, cuando recibeesetestigo,iterasobrelacolade
mensajes, envindolos al miembro especificado, o a todos los miembros si es un
mensaje multipunto. Si tiene variosmensajesmultipunto,lospuedeagruparenun
sloenvo,minimizandoelnmerodecomunicacionesydelegandoenelmiddleware
la divisin del mensaje en submensajes si aqul resulta demasiado grande. Para el
envodemensajes,lainterfazGroupHandlerincluyetresoperaciones:
receiveMessages:recibeconjuntosdemensajesmultipunto.
receivePTPMessages: la operacin equivalente para recibir mensajes punto a
punto.
SenseiGMS 126
confirmMessages:completaelenvodelosmensajes,queserealizaendospasos:
elmiembroenvaelmensajey,acontinuacin,confirmaquesepuedeprocesar.
Como un miembro puede enviar varios mensajes, el envo de un segundo
mensaje directamente confirma el primero y slo es necesario realizar una
confirmacin de mensajes en el ltimo paso, antes de liberar el testigo. Los
miembrosdelgrupoprocesanlosmensajesmultipuntoslocuandorecibenesta
confirmacin, mientras que los mensajes punto a punto no necesitan,
evidentemente,unaconfirmacin.
Si el miembro se cae antes de enviar todos los mensajes, el algoritmo de
recuperacin del testigo debe verificar los mensajes procesados por los miembros
activos, de tal forma que esos mensajes sean procesados por los dems miembros.
Cadamensajeincluye,porlotanto,unaidentidaddemensaje,conlavistaenquese
enva,yunnmerosecuencialquesereiniciaencadanuevavista.Larecepcinde
un mensaje con mayor nmero secuencial confirma automticamente al anterior.
Los mensajes deben, entonces, encolarse cuando se reciben y cada miembro
almacenalaidentidaddelltimomensajeprocesado,queesutilizadoenelalgoritmo
de recuperacin del testigo. Esta identidad de mensaje, que no se mostr con la
interfazprivada,esenOMG/IDL:
structMessageId
{
longview;
longid;
};
Un miembro que recibe un mensaje punto a punto de otro miembro da
automticamente por confirmados sus anteriores mensajes multipunto; sin
embargo, el mensajepuntoapuntonopuedeincrementarsuidentidaddemensaje
(id, el nmero secuencial), ya que no lo reciben todos los miembros. Por ello, en la
identidad de los mensajes punto a punto, slo tiene significado la identidad de la
vistaynoelnmerosecuencialasociado.
8.2.4.Manejodevistas
Todos los miembros del grupo deben recibir las mismas vistas. stas pueden
ser temporales, cuando los miembros discuten su contenido, o permanentes. La
aplicacin slo recibe las permanentes y se garantiza que todos losmiembrosdela
aplicacin reciben las mismas vistas. Sin embargo, no es necesario que todos los
miembrosrecibanlasmismasvistastemporales.
Las vistas se envan a travs de la operacin receiveView en la interfaz
SenseiGMSMember. Una vista es enviada cuando un miembro desea cambiar la
composicin del grupo, bien sea por la insercin de nuevos miembros, o tras
sospechar que un miembro ha cado y debe ser expulsado. Cada vista viene
SenseiGMS 127
identificada por una identidad de vista, e incluye la lista ordenada de los dems
miembrosdelgrupoysusidentidades,ascomolasdelosmiembrosquesonnuevos
enelgrupo(identidadesquenosonluegopropagadasconlasvistaspblicas).Esta
lista es ordenada, pero no se puede asegurar que el primer miembro sea el ms
antiguodelgrupo.
Siguiendo el modelo de sincrona virtual, los mensajes deben ser procesados
por todos los miembros en la misma vista. Los cambios de vistas bloquean, por lo
tanto, este envo. Cada miembro vlido puede estar en tresestados:vista instalada,
vista temporal, y vista temporal recibida. Cuando un miembro en estado de vista
instaladaenvaunanuevavista,debeprimeroenviartodoslosmensajesybloquear
el envo de nuevos mensajes, antes de pasar a estado de vista temporal. En este
estado, cuando la aplicacin solicita el envo de un mensaje, se le notifica que no
serenviadohastalasiguientevista.
Las vistas se instalan en dos pasos; un miembro enva su vista, que siempre
presenta una identidad temporal y, a continuacin, pasa el testigo al siguiente
miembro de la vista. Todos los miembros recibirn este testigo y podrn cambiarel
contenido de la vista; en este caso, sern nuevas vistas temporales. Si el miembro
queenvalavistarecibeeltestigosinquelavistahayacambiado,considerarquela
vistaesvlidaylapropagarcomopermanentealaaplicacin.
Cuandounmiembrorecibeunavista,pasaaestadodevistatemporalrecibida.
Cuandorecibeneltestigoenlasiguientevuelta,tienenunaoportunidadparaenviar
sus mensajes y, a continuacin, pasan a estado de vista temporal, bloqueando
igualmente los mensajes. Un miembro en vista temporal pasa a vista instalada
Figura8.1.Estados devistasenSenseiGMS
SenseiGMS 128
cuando recibe el testigo en la siguiente vuelta; si, estando en vista temporal, recibe
una vista de otro miembro, pasa a vista temporal instalada sin desbloquear los
mensajes.Eldiagramadeestadosenlafigura8.1visualizaestealgoritmo.
Hay un caso especial: un miembro en estado de vista temporal que recibe un
mensajepertenecienteaunavistaposterior.Estecasoimplicaqueotromiembroen
el anillo ha pasado ya a estado de vista instalada y enva nuevos mensajes; como
consecuencia,pasa,automticamente,aestadodevistainstaladaylocomunicaala
aplicacin.
8.2.5.Gestindegrupos
Ungruposecreaapartirdeunnicomiembro,quecreauntestigoinicialque
se enva a s mismo. Esta aproximacin se puede optimizar para evitar el paso del
testigocuandohayunsolomiembroenelgrupo.Paraextenderelgrupo,elpotencial
miembro debe contactar a alguno de los miembros vlidos, y solicitar su insercin.
Este miembro encolar esa solicitud y, cuando reciba el testigo, considerar si el
estado del grupo permite la insercin de nuevos elementos. Esta consideracin se
tieneencuentaacontinuacin,alexplicarloscambiosdevistas.
Los siguientes mtodos de la interfaz SenseiGMSMember son necesarios para
cubrirestafuncionalidad:
createGroup.
addGroupMember. Incluye eventualmente al miembro especificado como
parmetrodelaoperacinenelgrupopropio.
joinGroup. Es un mtodo redundante, definido en funcin de addGroupMember,
quebloquealallamadahastaquesecompletalainsercinenelgrupo.
Tras recibir una solicitud de inclusin en el grupo, el miembro contactado
aadir, eventualmente, a ese miembro o nuevos miembros, creando una nueva
vista que enva al grupo que incluye a esos nuevos miembros; stos, alrecibiresta
vista,puedenyaconsiderarseaceptadosenelgrupo.Esteprocesopuedefallarsiel
miembrocontactadosecaeopierdeelconsenso,encuyocaso,losnuevosmiembros
debernrepetirlasolicitudaotromiembro.Laobtencindereferenciasamiembros
existentesnoquedacubiertaenladefinicindelalgoritmo.
Para abandonar voluntariamente un grupo, un miembro debe enviar, cuando
recibeeltestigo,unavistaquenoleincluyay,acontinuacin,liberareltestigo.Un
miembro queabandonadeestaformaelgrupoafectaalaformaenqueseresuelve
elconsenso,excluyndolodelaanteriorvistapermanentealcontabilizarlamayora.
Por ejemplo, en condiciones normales, un grupo de dos miembros donde uno cae
pierdeelconsenso,peroestonoocurresielmiembrosolicitasuexclusin.
Esteprotocolonosoportaelconceptodegruposexclusivos:cualquierinstancia
deltipoSenseiGMSMemberpuedesolicitarsuinclusinenotrogruposiobtieneuna
SenseiGMS 129
referencia vlida y ninguno de los miembros existentes puede vetar tal inclusin.
Desde elpuntodevistadeseguridad,implica,porejemplo,queunmiembropodra
ser incluido y enviar entonces vistas errneas diferentes a distintos miembros del
grupo, provocando que ste se particione en grupos sin consenso. Esta seguridad
puede, sin embargo, incluirse en una capa superior. Por ejemplo, empleando
JavaRMI, es posible especificar una factora propia de sockets que emplee sockets
seguros o valide todo inicio de comunicaciones: sin afectar a SenseiGMS, la
aplicacinhasuperpuestounniveldeseguridadenlascomunicaciones.
8.2.6.Protocoloderecuperacindeltestigo
Unmiembroquenorecibeningunacomunicacintrasundeterminadoperiodo
detiempoconsideraqueeltestigosehaperdidoeiniciaelprotocoloderecuperacin
de aqul. Este protocolo se realiza en tres fases. En la primera fase, el miembro
contacta a los dems miembros a travs de la operacin allowTokenRecovery,
solicitndoles su permiso para recuperar el testigo. Si alguno de los miembros
respondenegativamente,estemiembroabortalarecuperacindeltestigo.
Unmiembrorespondenegativamentepordosposiblesrazones:porqueposeael
testigo, o porque tenga prioridad para recuperarlo. La segunda razn busca evitar
quedosmiembrosrecuperensimultneamenteeltestigo.Unmiembroconsideraque
tieneprioridadsobreotrosisuidentidaddevista(temporal/permanente)essuperior
a la del otro miembro y, cuando es igual, si su identidad de miembro de grupo es
superior a la del otro miembro; de esta forma, si un miembro ha enviado su
propuesta de vista a un subconjunto del grupo y se cae, ese subconjunto tiene
prioridad para instalar una nueva vista. La solicitud de recuperacin del testigo
incluye, por lo tanto, la identidad de vista del miembro que enva la solicitud. Al
responder, los miembros incluyen, igualmente, la identidad del ltimo mensaje
procesado, de tal manera que sea posible conocer la mayor identidad de mensaje
procesadoporalgnmiembroenelgrupo.
En la segunda fase, el miembro considera que puede recuperar el testigo, y
enva su decisin a los dems miembros, empleando la operacin recoverToken.
Cuandoestosmiembrosrecibenestaseal,consideranqueeltestigosehaperdidoy
que est siendo regenerado por el miembro dado. El grupo no aceptar entonces
ninguna nueva comunicacin del grupo (paso de testigo, o mensajes, etc.),
aceptando nicamente otra comunicacin recoverToken o un cambio de vista
provenientedelmiembroqueestrecuperandoeltestigo.Deestamanera,seimpide
queelanteriortestigocauseproblemassielmiembroqueloposeaeramuylentoo
simplemente haba un problema en las comunicaciones de red. Se impide tambin
que dos miembros puedan recuperar el testigo simultneamente, tambin por
problemas de comunicaciones. Si fuera ste el caso, el grupo se dividira entre los
miembros que han recibido las solicitudes de recuperacin de cada miembro;
eventualmentesepuedeprovocarqueelgruposevuelvainoperativo,peroimpidela
SenseiGMS 130
inconsistencia de que dos miembros consideren que poseen el testigo y enven
simultneamentecomunicacionescontradictoriasalgrupo.
Enlatercerafase,elmiembroenvalavistaalosmiembros.Estavistaexcluye
a los miembros que no pudo contactar en la primera o segunda fase y a los
miembros que respondieronnegativamentealeventoderecuperacindeltestigo.Si
tras estas exclusiones el miembro ha perdido el consenso, se considera
automticamenteexcluido.
Un miembro que es expulsado del grupo cuando no tiene el testigo ejecutar
eventualmente este protocolo, descubriendo que no tiene consenso para continuar
operativo, enviando entonces el evento de exclusin de grupo a la aplicacin. Si el
miembroesexpulsadocuandotieneeltestigo,fracasarensuintentodetransferirlo
y, de nuevo, al intentar instalar una vista, detectando entonces su prdida de
consensoigualmente.
8.3.UsodeSenseiGMS
Elsiguientecaptulo,dedicadoalametodologadediseodegruposdeobjetos
replicados,secentraenlosproblemasgeneralesaldisearaplicacionestolerantesa
fallos y muestramtodosgenricosylasherramientasnecesariasparasoportaresa
metodologa. Esta seccin se limita a mostrar un ejemplo particular sobre
SenseiGMS, obviando, al menos, un problema de uso que con las herramientas
mostradasenelsiguientecaptulotendraunafcilsolucin.
8.3.1.Diseodeunservicioreplicado
La seccin dedicada al diseo de SenseiGMS mostr su interfaz pblica y las
directricesgeneralesparaemplearreplicacindeobjetos:definirlosmensajesquese
emplearnenlascomunicacionesdelgrupo,implementarlainterfazGroupMembery
obtenerunareferenciaaunobjetoGroupHandler,yaseacreandounnuevogrupoo
incluyndose en uno existente; mediante esta referencia se accede al grupo, y es
precisoprocesarlosmensajesprovenientesdeste.
El ejemplo a implementar es un caso real: un servicio de directorio de
miembros degrupos,detalformaquenuevosmiembrospuedanobtenerfcilmente
referenciasaotrosmiembrosyaexistentesenundeterminadogrupo,quesenombra
mediante una cadena de caracteres. Este es uno de los servicios existentes en
Sensei, denominado SenseiGMNS, con una interfaz ms complicada para ser
funcionalalosclientesdelgrupoynosloasusmiembros.
Para implementar este servicio, empleamos una estructura de datos
denominada GMNSdata, que contiene una lista de todos los grupos existentes y,
para cada grupo, la lista de miembros asociados. Si la mquina que contiene esta
SenseiGMS 131
estructura se cae, el servicio se vuelve inaccesible, por lo que la implementacin
debesertoleranteafallos:esuncomponentereplicado.
Ladefinicindeestecomponentees,enOMG/IDL:
interfaceGMNSdata:GroupMember
{
voidinsert(instringgroupName,inGroupHandlermember,instringmemberName);
voidremove(instringgroupName,inGroupHandlermember);
GroupHandlerget(instringgroupName);
};
Lasoperacionessedefinencomo:
insert: incluye un miembro en el grupo dado, creando el grupo si es necesario.
Cadamiembrotieneunnombre,solamentetilparasuvisualizacin.
remove:eliminaunmiembrodelgrupoyelgrupomismosisequedavaco.
get:devuelveunelementocualquieradeungrupo.
Un miembro que desea incluirse en un determinado grupo, accede a este
componente
3
mediante la operacin get para obtener referencias a otros miembros
del grupo. Si no hay referencias, crea el grupo e introduce en este componente su
referencia con la operacin insert. Si hay otros miembros, getdevuelveunodeesos
miembros, al que solicita su inclusin en el grupo, insertando finalmente en este
componente su referencia. Sin embargo, hay problemas de concurrencia: puede
darseelcasodedosfuturosmiembrosdeunmismogrupo,todavanoexistente,que
accedan a este componente, observando ambos que el grupo no existe y creando
entonces dos grupos independientes, para insertar, a continuacin, sus referencias
bajoelmismonombredegrupo.Paraesteejemplo,obviamosesteproblema,quese
trataenlossiguientescaptulos.
Si un componente GMNSdata recibe una solicitud insert o remove, debe
comunicrselo a las dems rplicas GMNSdata de tal forma que todo el grupo
mantenga el mismo estado. Si la solicitud es get, el componente puede dar esa
informacinsinrealizarningunacomunicacinalgrupo.Definimosdosmensajes:
valuetypeGMNSdataInsertMessage:valuetypeGMNSdataRemoveMessage:
MessageMessage
{{
publicstringgroupName;publicstringgroupName;
publicstringmemberName;publicGroupHandlermember;
publicGroupHandlermember;};
};
3
Tal acceso no es directo, un componente intermedio, el GMNS, es el encargado de acceder
ordenadamentealGMNSdata,evitandocolisionesbajomltiplessolicitudes.
SenseiGMS 132
Cada mensaje incluye la informacin necesaria para poder ejecutar en cada
rplicaelmismocdigo,loque,engeneral,suponeincluircomoatributoscadauno
delosparmetrosdefinidosenlaoperacinasociada.
Desde un punto de vista formal, no es preciso que GMNSdata herede de
GroupMember: es suficiente que se defina un componente que implemente ambas
interfaces.
8.3.2.Implementacin
La implementacin es diferente si se emplea JavaRMI o CORBA y, en este
ltimo caso, vara segn el lenguaje de implementacin escogido y el adaptador de
objetos empleado. En el caso de emplear Java bajo CORBA, usando el Portable
Object Adapter, una implementacin posible es crear una clase que herede de
GMNSdataPOA, que es generada automticamente por el compilador de OMG/IDL.
Con RMI, una posibilidad es crear una clase que herede de
java.rmi.server.UnicastRemoteObject e implemente la interfaz GMNSdata. En ambos
casos, el algoritmo es el mismo y, puesto que en los dos casos se emplea Java, el
cdigo que implementa la funcionalidad GMNSdata es comn para CORBA y RMI.
Paranoentrarendetallesinnecesariossobreesteejemploconcreto,suponemosque
existeunaestructuradedatosinternacapazdemanejarlalgicadelproblema(sin
replicacin) y con las mismas operaciones definidas en la interfaz GMNSdata (sin
incluir las operaciones de GroupMember). La instancia de esta estructura la
denominamosinternalGMNSData.
La figura 8.2 muestra la idea bsica para el procesado de mensajes en este
ejemplo:alrecibirunasolicituddeservicio,larplicanolaprocesainmediatamente,
sinoqueenvaunmensajealgrupoconlainformacinsobrelaoperacinarealizar.
El miembro que enva el mensaje, tambin lo recibe, en el orden adecuado, y es
entonces cuando procesa la operacin. La ventaja de esta aproximacin esquehay
un nico punto de procesamiento, tanto para las operaciones directamente
invocadas en esta rplica, como para los mensajes provenientes de esas mismas
operacionesalserinvocadassobreotrasrplicasdelgrupo.
Este ejemplo es un caso simplificado pues, normalmente, el servidor debe
devolveralgnvaloralclienteyesentoncesnecesariosincronizardealgunamanera
lainvocacindelaoperacinconsuprocesamiento,comodetallamosenelsiguiente
captulo. Incluso en este simple ejemplo, no puede garantizarse que la siguiente
porcindecdigoseejecutesatisfactoriamente:
map.insert(GrupoA,specificGroupHandler,Miembro1);
if(map.get(GrupoA)==null)
{
//Error,elgruponotienemiembrostrashaberinsertadouno?
}
SenseiGMS 133
El motivo de este error es que cuando la operacin insert vuelve, no ha sido
anprocesada,porloqueelvalordevueltoporlaoperacingetpuedeindicarqueel
grupo dado no tiene ningn miembro. Y si la operacin se sincroniza, la principal
desventajaeselmayortiempodeprocesoqueelclienteexperimenta.Enlasiguiente
lista aparecen en cursiva los pasos que deben ser ejecutados en adicin al proceso
normal,sielservidornoestuvierareplicado:
Recibirlapeticindelcliente.
Crearunmensajeconlainformacindelaoperacinaprocesar.
Enviarestemensajealgrupo.Locualincluyeenviarelmensajeacadaunadelas
rplicas garantizando que todas obtienen una copia. En el peor caso, implica
enviaracadarplicatresmensajes.
Recibirelmensaje.
Procesarlaoperacinsolicitada.
Sincronizar este procesamiento con la operacin invocada para poder devolver al
clientelosresultadosdeesaoperacin.
Devolveralclientelosresultadosdelaoperacin,sifueranecesario.
Estospasosadicionalesdebenejecutarseencualquiercasoenuncomponente
replicado activamente, pero el cliente no experimenta estos mayores tiempos de
procesamiento si el sistema se programa de tal forma que los mensajes sean
dinmicamente no uniformes. En ese caso, cuando un cliente invoca la operacin
insert, el servidor la procesa inmediatamente y enva a continuacin (o incluso
Figura8.2.Tratamiento demensajesempleandoordentotal.
insert
castMessagetothegroup
processCastMessage
ProcessInsertMessage
/**
*Insertmemberintotheinter
*andcheckforitscorrectenes
*@paramInsertMessage cont
*@paramsenderdefinesthe
*@throwsMemberStateExce
**/
voidprocessInsertMessage()
--------------------------------------
==>Aquseprocesala
operacin.
insert
castMessage tothe group
processCastMessage
/**
* Insert memberinto the inter
* andcheck foritscorrectenes
* @param InsertMessage cont
* @param senderdefinesthe
* @throwsMemberStateExce
**/
void processInsertMessage()
insert
castMessage to thegroup
processCastMessage
/**
*Insert member into theinter
*and checkforits correctenes
*@param InsertMessage cont
*@param senderdefines the
**/
insert
castMessage to thegroup
processCastMessage
/**
*Insert member into theinter
*and checkforits correctenes
*@param InsertMessage cont
*@param senderdefines the
**/
insert
castMessage tothe group
processCastMessage
/**
* Insert memberinto the inter
* andcheck foritscorrectenes
* @param InsertMessage cont
* @param senderdefinesthe
* @throwsMemberStateExce
**/
void processInsertMessage()
cliente
SenseiGMS 134
concurrentemente) el mensaje al grupo, pero el cliente observa el mismotiempode
procesamiento que si el servidor no estuviera replicado. Obviamente, el servidor
tiene ahora una mayor carga de trabajo, por lo que no ser capaz de soportar el
mismonmerodeoperacionesporunidaddetiempo.
Emplearmensajesdinmicamentenouniformesimplicanormalmentecambiar
los algoritmos de los grupos, pues no todas las rplicas procesan los mismos
mensajes en el mismo orden: la rplica que enva el mensaje no lo procesa. Por
ejemplo, al programar una estructura de datos que implemente un mapareplicado,
estos mensajes producirn, normalmente, inconsistencias en el grupo: si dos
miembros insertan concurrentemente dos valores distintos para una misma clave,
las rplicas terminarn con estados diferentes. Esta restriccin no se da, sin
embargo,enelcasodeGMNSdata,dondeelvalordecadaentradadelmapaes,asu
vez,unconjuntodevaloressinrequerimientosdeorden.
El siguiente cdigo implementa un servidor replicado GMNSdata usando
SenseiGMSbajoJavaRMIyempleandomensajesdinmicamenteuniformes:
publicclassGMNSdataImplextendsUnicastRemoteObjectimplementsGMNSdata
{
publicGMNSdataImplthrowsRemoteException{}
publicvoidinsert(StringgroupName,GroupHandlermember,StringmemberName)
{
handler.castMessage(newGMNSdataInsertMessage(groupName,member,memberName));
}
publicvoidremove(StringgroupName,GroupHandlermember)
{
handler.castMessage(newGMNSremoveMessage(groupName,member));
}
publicGroupHandlerget(StringgroupName)
{
returninternalGMNSdata.get(groupName);
}
publicvoidprocessCastMessage(intsnd,Messagemsg)
{
if(msginstanceofGMNSdataInsertMessage)
{
GMNSdataInsertMessageiMsg=(GMNSdataInsertMessage)msg;
internalGMNSdata.insert(iMsg.groupName,iMsg.member,iMsg.memberName);
}
elseif(msginstanceofGMNSdataRemoveMessage)
{
SenseiGMS 135
GMNSdataRemoveMessagerMsg=(GMNSdataRemoveMessage)msg;
internalGMNSdata.remove(rMsg.groupName,rMsg.member);
}
}
publicvoidchangingView(){}
publicvoidvoidinstallView(Viewview){}
publicvoidprocessPTPMessage(intsnd,Messagemsg){}
publicvoidmemberAccepted(intid,GroupHandlerhandler,Viewview)
{
this.handler=handler;
}
publicvoidexcludedFromGroup()
{
System.exit(0);
}
GroupHandlerhandler;
}
Esteservidornonecesitainformacinsobrelasdemsrplicas,luegonoprocesa
las vistas que recibe, y no necesita cdigo en las operaciones installView o
changingView. Cuando el miembro es aceptado en el grupo, recibe mediante
memberAccepted una instancia del tipo GroupHandler, que guarda para utilizar
posteriormenteensusinteraccionesconelgrupo.
El algoritmo noprecisademensajespuntoapunto,luegotampocoesnecesario
ningn cdigo en processPTPMessage. Al recibir mensajes del grupo en
processCastMessage debe primero discernir el tipo de mensaje recibido,
procesndolos acordemente. Si el mensaje es GMNSdataInsertMessage, lee la
informacin del mensaje e invoca esa operacin sobre la estructura de datos
interna,tratandodeformasimilarelmensajeGMNSdataRemoveMessage.
Lasoperacionesinsertyremovesetratancreandolosmensajescorrespondientes
y envindolosalgrupoatravsdelainstanciaGroupHandlerrecibidacuandoel
miembrofueaceptado.
Laoperacingetesprocesadainmediatamente,empleandolaestructuradedatos
interna.
El cdigo mostrado no trata errores (la instancia de GroupHandler es remota,
luego su acceso puede siempre provocar excepciones) ni realiza transferencia de
estado,peromuestralascaractersticasfundamentalesdeSenseiGMS:orientacina
SenseiGMS 136
objetos, empleo de mensajes tipados, comunicaciones en grupo fiables con orden
total. Es posible llevar la orientacin a objetos ms lejos empleando herramientas
genricasquedefinanlosmensajesautomticamenteapartirdeunainterfazdaday
transformen la recepcin de mensajes en llamadas a procedimientos especficos
segnelmensajerecibido;estetemasetratatambinenelsiguientecaptulo.
Tampoco muestra este cdigo cmo se crea o se extiende el grupo: si la
implementacin se realiza totalmente en Java, la clase ActiveGroupMember en el
paquete sensei.GMS implementa la interfaz SenseiGMSMember, necesaria para la
creacinoextensindegrupos.Elprimermiembrocreaunainstanciadeestaclase
einvocalaoperacincreateGroup.Elsegundoyposterioresmiembrosdebenobtener
de alguna manera una referencia a este miembro, por ejemplo, accediendo a un
fichero donde esa referencia se haya guardado. Estos miembros crean de la misma
forma una instancia de la clase ActiveGroupMember e invocan la operacin
joinGroup, pasando la referencia del primer miembro del grupo. Este proceso se
realiza automticamente y sin necesidad de discernir entre primero o posterior
miembrodelgrupoempleandoSenseiGMNS,detalladoenelcaptulo11.
8.3.3.Configuracin
El algoritmo emplea varias variables que pueden cambiar el comportamiento
del sistema, permitiendo as su optimizacin en funcin del entorno de trabajo.
Estaspropiedadesson:
GMS.channelLiveness: periodo en milisegundos en que un canal de
comunicacin espera una respuesta. Transcurrido este tiempo, el miembro
correspondienteseconsideracado.Pordefectoson10segundos.
GMS.maxProcessMaxDelay: periodo en milisegundos que define el retraso
mximoenquelaaplicacinpuedeprocesarunmensajedado.Transcurridoeste
tiempo, que por defecto es de 5 segundos, Sensei considerar que la aplicacin
esmuylentayexcluiralcorrespondientemiembrodelgrupo.
GMS.tokenStoppedPeriod: retencin del testigo en caso de inactividad en el
sistema. Cuando el sistema no realiza ninguna comunicacin, cada miembro
retieneeltestigoeltiempodadoporestavariable,50milisegundospordefecto.
GMS.tokenLostTimeout: periodo en milisegundos que tarda un miembro que no
recibeningunacomunicacineniniciarelalgoritmoderecuperacindeltestigo.
Pordefecto,esde6segundos.
GMS.weakConsensus: si esta variable booleana se define a true, se emplea un
modelo de consenso dbil, donde essuficientequelamitaddelosmiembrosde
unavistasobrevivanparaqueelgrupoconserveelconsenso.
Estas propiedades se definen en un fichero especfico, aunque cada grupo
puede definir configuraciones distintas o, simplemente, redefinir alguno de los
SenseiGMS 137
anteriores valores. No es necesario tampoco que todos los miembros de un mismo
grupodefinanlamismaconfiguracin.
8.4.VirtualNet
SenseiGMS se ha probado en profundidad, comprobando situaciones lmite
mediante el empleo de instancias de SenseiGMSMember con una implementacin
deliberadamente errnea del algoritmo expuesto. Estas alteraciones del algoritmo
incluyen:
Losmensajesnosonenviadosatodoslosmiembrosenelgrupo.
Lavistanoseenvaatodoslosmiembros.
Laconfirmacindelosmensajesnoseenvaatodoslosmiembros.
Losmensajesnoseenvanhastaqueserecibeuncambiodevista.
Losmensajesnoseenvanhastalasiguientevista.
Se retrasa la insercin de los miembros que lo solicitan hasta que se reciba un
cambiodevista.
Elpasodeltestigoserealizalentamente.
Miembrossecaenensituacionescomprometidas.
Comprobar el comportamiento de Sensei en condiciones reales es una tarea
ms complicada, al precisar de entornos muy variados. Por ejemplo, comprobar un
enlace ms lento, o la cada de uno o ms enlaces, es difcil de realizar, incluso
cuando sea posible realizar la desconexin manual de esos enlaces fsicos. Un
entorno real puede involucrar ordenadores fsicamente muy distantes, conectados
por Internet a travs de un nmero desconocido de nodos, donde estos nodos
pueden caerse o donde algunas conexiones pueden tener grandes fluctuaciones de
rendimiento. Para solucionar este problema, hemos desarrollado una aplicacin
independientedeSenseidenominadaVirtualNet.
La filosofa de VirtualNet es simple: simular una red en un solo ordenador,
donde se pueden definir nodos y enlaces que pueden alterarse en cualquier
momento, ya sea definiendo diferentes rendimientos o desactivando temporal o
permanente esos nodos o enlaces. Cada miembro debe asociarse a un nodo, y sus
comunicacionesconotrosmiembrossuponenquedebeexistirunarutavirtualentre
susnodos.
La versin inicial de VirtualNet slo funciona con JavaRMI, empleando un
compilador propio para generar los stubs y skeletons, que verifican esa ruta virtual
antes y despus de acceder al objeto remoto. La forma de asociarse a un nodo es
empleando el servicio de nombrado de RMI (java.rmi.Naming), que se redefine para
VirtualNet. As, en lugar de emplear java.rmi.Naming, se emplea vnet.remote.Host,
SenseiGMS 138
que define exactamente la mismo interfaz,facilitandolapruebadelasaplicaciones.
Slo debe cambiarse el nombre con que se publica la aplicacin, que debe ser del
tipo: /virtualNetName/Host/Server(nombre de la red virtual creada, mquina a
emplear,nombredelservidor).Porejemplo,/redMadrid/MaquinaUCM/GMNS.
Una aplicacin no necesita, sin embargo, emplear el registro de RMI para
operar. Este registro es slo una forma cmoda de obtener referencias a otros
objetos remotos existentes. De hecho, Sensei no emplea el registro en ningn
momento. Por esta razn, se ha desarrollado una nueva versin que, por el
contrario,funcionademomentosloconCORBA.VirtualNetcontieneahoralalgica
paracomprobarlasrutasvirtualesentredosnodoscualesquiera,nodosalosquese
les puede asignar cualquier nombre. Puedesoportarmltiplesredesvirtuales,cada
una de las cuales se instala en un determinado puerto. La aplicacin final debe
conectarse a este puerto, indicando el nombre de la mquina en que reside y, a
continuacin, puede consultar indefinidamente si hay rutas virtuales a otras
mquinas. VirtualNet dispone de una interfaz grfica que permite visualizar
dinmicamenteelestadodelaredvirtual,talcomomuestralafigura8.3.
Losenlacespuedensermonodireccionalesobidireccionalesy,tantolosnodos,
comolosenlaces,puedentenerunretrasoasociadoqueseprocesaencadachequeo
deruta.Esdecir,alcontactarseVirtualNetparachequearsiunarutaesvlidaono,
una respuesta positiva se efectuar en el tiempo necesario para recorrer
virtualmentecadaunodelosnodosyenlacesenlarutacalculada.Puedenrealizarse
varioschequeossimultneamente.
Figura8.3.VirtualNet
SenseiGMS 139
El protocolo de acceso a VirtualNet es muy simple y una aplicacin en
cualquier lenguaje puede emplearlo para comprobar las rutas. Sin embargo, es
necesarioqueestosaccesosseanlomstransparentesposibleparaqueelempleode
esta herramienta sea prctico. Bajo CORBA es posible implementar interceptors,
cuyo objetivo es interceptar cualquier acceso remoto. VirtualNet incluye
interceptores que acceden a la red virtual en cada acceso y emiten excepciones
org.omg.CORBA.COMM_FAILURE cuando la ruta no es vlida. Para ello, aaden en
cadacomunicacinelnombredelamquinaquerealizalacomunicaciny,cuando
el servidor recibe esa comunicacin, puede chequear la ruta. De la misma forma,
cuandoelservidordevuelvelarespuestaalcliente,stepuedevolveracomprobarla
ruta.
Para que una aplicacin emplee VirtualNet debe incluir la siguiente lnea de
cdigoalprincipiodelprograma,antesdeiniciarelORB
4
:
args=vnet2.OOCInterceptor.setup(null,args,props);
El primer parmetro indica el receptor de los mensajes de error que, por

defecto, es el dispositivo normal de salida. El segundo parmetro contiene los
argumentos de la lnea de comando y, el tercero, las propiedades con que se
inicializar posteriormente el ORB. Los argumentos asociados a VirtualNet son
eliminados para no interferir con la lgica de la aplicacin. Estos argumentos
requeridosson:
-virtualNetHost host: indica la mquina donde se ejecuta el programa de
VirtualNetque,pordefecto,eslocalhost.
-virtualNetPortport:indicaelpuertodondeVirtualNetesperaconexiones.
-virtualHostNamename:indicaelnombredelamquinavirtual,quedeberestar
definidoenlaredvirtualasociada.
Si los dos ltimos argumentos estn presentes, el interceptor seinstalacomo
clienteycomoservidor,yseempleaentoncesactivamentelaredvirtual.
8.5.Conclusiones
SenseiGMSesunsistemadecomunicacionesfiablesengrupoqueimplementa
sobre CORBA y JavaRMI una interfaz de programacin de aplicaciones similar al
soportado en otros sistemas de comunicaciones en grupo. La funcionalidad
implementada se reduce a la mnimacomnconesossistemasdecomunicaciones,
de tal forma que la implementacin posterior, tanto de los algoritmos de
4
EnesteejemploseestempleandoelinterceptorOOC,especficoparaOrbacus.
SenseiGMS 140
transferencia de estadoexpuestos,comodelasherramientasdeapoyoaldesarrollo
de aplicaciones replicadas mostradas en los siguientes captulos, pueda
reimplementarsesincambiosencualquiersistemadecomunicacionesengrupo.
La necesidaddeSenseiGMSsehabasadoenlanodisponibilidaddesistemas
similares sobre CORBA o JavaRMI. La especificacin del servicio de tolerancia a
fallos de CORBA define, para la replicacin activa, un grupo de comunicaciones en
sincrona virtual situado lgicamente por debajo del ORB, con el objetivo de lograr
un mejor rendimiento. SenseiGMS implementa el sistema de comunicaciones sobre
el ORB, degradando su rendimiento en beneficio de una simplificacin en su
implementacin. Cuando est disponible una implementacin compatible con la
actual especificacin, confiamos en la fcil migracin de la interfaz de SenseiGMS
sobreesaimplementacin,teniendoencuentalamnimafuncionalidadsoportada.
SenseiGMS define, sin embargo, dos facilidades adicionales sobre otros
sistemas de comunicaciones en grupo tradicionales: orientacin a objetosysoporte
de mensajes tipados. Estas dos facilidades no resultan, por otro lado, difciles de
implementarsobreesossistemas.
El objetivo de simplificar la implementacin de SenseiGMS afecta, tambin, a
susoportedeordenenlosmensajesfiables,admitiendosloordentotal.Esteorden
se obtiene mediante un algoritmo de paso de testigo, diseado sobre mensajes
fiables punto a punto. Las aplicaciones replicadas se programan ms fcilmente
empleando ordentotalquecausalofifo,yeldiseodeherramientasgenricasest
tambinbasadoeneseorden,loquegarantizaqueestasimplificacin,especficaen
lafuncionalidaddeSenseiGMS,noafectaaldominiodeaplicacionesquesoporta.
Probar la correccin de SenseiGMS,ascomodelasaplicacionesquelousan,
implica la misma problemtica asociada a sistemas distribuidos, donde deben
probarse procesos ejecutndose sobre mltiples mquinas. Aqu se aade el
problema de probar los enlaces mismos, pues los algoritmos empleados son muy
dependientes de cualquier retraso o alteracin en las comunicaciones. Con el
objetivo de cubrir esta necesidad, VirtualNet permite simular una red de cualquier
complejidad sobre una nica mquina, ofreciendo facilidades para alterar su
topologa y la calidad de las comunicaciones en cualquier momento. Adems, su
empleo no implica importantes cambios en la aplicacin a probar, limitndose su
impactoalaadicindeunasimplelneadecdigoalprincipiodelprograma.
Metodologadedesarrollo 141
Captulo9-METODOLOGADE
DESARROLLO
La replicacin de una aplicacin es esencial para hacerla tolerante a fallos,
pero esa replicacin resulta cara de realizar. Adems de la duplicacin de recursos
hardwarequeprecisa,hayunimpactonegativoenelrendimiento,yaseaenlacarga
de trabajo soportada, en el tiempo de respuesta de servicio o incluso en ambos
parmetros.
Empleando replicacin activa, las rplicas deben mantener su consistencia
mutuacontinuamente,porloquetodaactualizacinenunarplicadebepropagarse
alasdems.Elimpactodeestapropagacindependedelsistemadecomunicaciones
en grupo y su algoritmo empleado. El protocolo optimizado de Totem [Totem]
requiere, por ejemplo, dos vueltas y media del testigo para entregar fiablementeun
mensaje en orden total. SenseiGMS requiere para el mismo cometido media vuelta
deltestigomselenvodetresmensajesalmiembromslentodelgrupo,aunquela
eficiencia se incrementa cuando un miembro enva varios mensajes en la misma
vuelta.
Y esta propagacin sobre el grupo es requerida para cada actualizacin en la
aplicacin en condiciones normales. Si el grupo formadoporlasrplicascambiasu
composicin, pierde su disponibilidad mientras se negocianloscambios,yesdifcil
calcular el impacto o duracin de este bloqueo. Por ejemplo, en SenseiGMS, un
cambiodebidoalainclusinoexclusinvoluntariadeunmiembroserealizaendos
vueltasdetestigo,mselenvodeunmensajealmiembromslentodelgrupo.Pero
si hay una particin del grupo o se cae el miembro que posee el testigo, debe
verificarse la regeneracin del testigo, comprobarse el consenso, enviarse nuevas
vistas,etc.
El coste de la replicacin activa puede reducirse empleando replicaciones
pasivas,dondelaconsistenciaslodebemantenerseaintervalosdadosdetiempo,o
inclusonunca,enelcasomssimple.Cuantomenorsealaconsistencia,mayoresel
tiemporequeridopararecuperarelservicioencasodequelarplicaprimariafalle.Y
adems, sigue existiendo un impacto continuo de rendimiento, pues esa rplica
primaria debe an guardar su estado en dispositivos persistentes. Sin embargo, la
especificacin del servicio de tolerancia a fallos de CORBA da un fuerte soporte al
empleodereplicacionespasivasy,aunquecubreelusodegruposactivos,susoporte
puede resultar insuficiente para aplicaciones complejas, como se detalla en este
captulo.
Sielempleodereplicacionespasivassuponemejorestiemposderespuestaen
lamayoradeloscasos,ofreceporotroladounamenordisponibilidadquepuedeser
prioritaria para determinadas aplicaciones como, por ejemplo, controladores de
dispositivos esenciales en un avin. Y si las aplicaciones pueden asegurar una
buena calidad de las comunicaciones entre sus rplicas, el coste de la replicacin
activapuedereducirseamrgenesperfectamenteaceptablesparatalesaplicaciones.
Por ejemplo, un servidor conectadoaInternet,dandoundeterminadoservicio
mediante Web, puede disponer de rplicas situadas geogrficamente de tal forma
que ningn cliente deba acceder a servidores fsicamente muy distantes, lo que
supondrapeorestiemposderespuesta.Ysilaconexinentrelasrplicasnosehace
mediante Internet, sino en una red con una calidad de servicio fija y elevada, los
tiemposrequeridosparaactualizartodaslasrplicaspuedenseradecuados,adems
de minimizar las probabilidades de indisponibilidad del grupo por cambios en su
composicin.
Para estos casos donde la red soporta unos parmetros de calidad de servicio
adecuados, es tambin posible emplear protocolos de comunicaciones optimizados,
como el desarrollado en Spinglass [Spinglass], redundando enunmejorserviciodel
grupo.
Entendidas las limitaciones asociadas al modelo de replicacin activa, este
captulo se centra en la programacin de aplicaciones tolerantes a fallos bajo ese
modelo. Empleando replicacin pasiva, es preciso modificar la aplicacin para que
almacene su estado de forma peridica, pero este cambio resulta mnimo al
compararlo con los cambios necesarios para emplear replicacin activa. Es posible
emplear diversas tcnicas que simplifiquen el desarrollo de aplicaciones replicadas
activamente, por lo que nos centramos en el soporte necesario para implementar
esas tcnicas; en particular, estudiamos el soporte ofrecido en CORBA, detallando
susinsuficienciasparaaplicacionesnobsicas.
Losproblemasderendimientoengruposactivospuedenprecisardealgoritmos
fuertementeoptimizadosyespecficosparaunaaplicacinconcreta.Sinembargo,el
enfoqueseguidoenestecaptuloesgeneralista,porloquenosbasamosenelempleo
deordentotalcausalenlascomunicaciones.Esdecir,todaslasrplicasrecibenlos
mismoseventosenelmismoorden,loquepermitedisearalgoritmosmsgenerales
ysimplesqueempleandordenesmenosestrictos.
9.1.Sincronizacindelarespuesta
En una aplicacin cliente/servidor, el servidor define una interfaz que el
clienteempleaparasolicitarsusservicios.Generalmenteelclientequedabloqueado
mientras el servidor procesa su solicitud, aunque esto no es siempre cierto, como
puede
5
ser el caso de las operaciones oneway en CORBA. En una aplicacin fiable,
este servidor debe contactar a las dems rplicas y obtener as una respuesta
consensuada, que es entonces entregadaalcliente;esteprocesoimplicaengeneral
la necesidad de sincronizar la solicitud del servicio con la elaboracin de la
respuesta.
Este problema fue brevemente esbozado en el captulo anterior, al desarrollar
unejemplodeusoconSenseiGMS,ymostradogrficamenteenlafigura8.2.Ahora
emplearemos una interfaz muy sencilla, con una nica operacin que muestra el
patrn general de diseo a emplear; esta interfaz es la de un servidor que genera
nmerosnicosdeformasecuencial,especificadoenOMG/IDLcomo:
interfaceNumberGenerator
{
longgetNumber();
};
Una posible implementacin de este servidor replicado se basa en que cada
rplica mantenga una variable con el ltimo nmero generado por el grupo. A esta
variableladenominamoslastGeneratedNumber.Cuandounadeestasrplicasrecibe
unapeticingetNumber,realizalossiguientespasos:
Enva un mensaje al grupo, de tal forma que todas las rplicas tengan
conocimientodequeestencursounapeticin.
Las rplicas, al recibir el mensaje previo, incrementan automticamente la
variable que almacena el ltimo nmero generado. Este paso tambin lo realiza
larplicaqueenvielmensaje.
5
El estndar CORBA [OMG98] no especifica que la invocacin de una operacin oneway deba
impedir el bloqueo del cliente en tanto el servidor la procesa. Sin embargo, un comportamiento no
bloqueanteresultaunaimplementacinlgicaygeneralizada.
Cuando la rplica que envi el mensaje lohaprocesado,puedeyadevolveruna
respuestaalcliente,elvalorcontenidoenlastGeneratedNumber.
Luego la rplica que enva el mensaje debe esperar la notificacin de que ha
sido procesado; la figura 9.1, similar a la figura 8.2, la extiende mostrando la
sincronizacinrequeridaeincluyeademsenpseudo-cdigoelescenariodescrito.
Es importante destacar que la secuencia previa de pasos no es correcta. Bajo
unaimplementacingeneraldethreadsohilosdecontrol,noesposibleasumirque
un determinado thread en estado de espera que pasa a estado activo reciba
inmediatamente tiempo de proceso. Por ello, es perfectamente posible que desde el
momentoenqueserealizalanotificacindequeelmensajehasidoprocesadohasta
que se lee el valor de la variable lastGeneratedNumber, la rplica procese otro
mensaje que modificara de nuevo esta variable, devolviendo consecuentemente un
valorerrneo.
La figura 9.2 muestra una alternativa a la anterior sincronizacin, ms
complicada pero necesaria en todas las operaciones que devuelven algn valor,sea
comoparmetrodesalidaocomovalorderetorno:
LarplicarecibeenunthreadlapeticingetNumber.Envaunmensajealgrupo,
detalformaquetodaslasrplicastenganconocimientodequeunapeticinest
encurso.
Esperaaqueelmensajesereciba,conloqueesethread(threaddeenvo)queda
suspendido.
processCastMessage
si elmensaje es del tipo
GetNumberMessage,
processGetNumberMessage()
siestainstanciaenvi el mensaje,
notificar quesehaprocesado
Process
GetNumber Message
++lastNumberGenerated
getNumber()
castMessage algrupo
esperar aqueseprocese
devolverlastNumberGenerated
processCastMessage
GetNumberMessage,
Process
GetNumber Message
getNumber()
castMessage algrupo
processCastMessage
GetNumberMessage,
Process
GetNumber Message
getNumber()
castMessage algrupo
devolver lastNumberGenerated
processCastMessage
GetNumberMessage,
Process
GetNumber Message
getNumber()
castMessage algrupo
Figura9.1.Sincronizacin delarespuesta
processCastMessage
GetNumberMessage,
Process
GetNumber Message
getNumber()
castMessage algrupo
cliente
Elmensajeserecibeenunthreadindependiente(threadderecibo);enlarplica
que envi el mensaje, este mensaje debe procesarse en el thread de envo. Por
ello,sedespiertaaesethread,yestethreadderecibopasaaestadosuspendido.
Lasdemsrplicasprocesanelmensajedirectamenteenelthreadderecibo.
Cuando el thread de envo despierta, procesa el cdigo asociado al mensaje,
incrementando el valordelavariablelastGeneratedNumber,queserdevueltaal
cliente.Acontinuacin,despiertaalthreadderecibo,quenodebehaceryanada
ms.ElthreaddeenvoterminatambinalcompletarselapeticingetNumber.
Esnecesarioenesteescenarioqueelthreadderecibonofinalicehastaquese
hayaprocesadoelmensajeenelthreaddeenvo;encasocontrario,larplicapodra
recibirnuevosmensajes,conloqueestaraprocesandooperacionesenparalelo,con
resultados imprevistos salvo que incluyera sus propias opciones de sincronizacin,
loquecomplicadenuevoelescenario.
Enestesegundocaso,cuandounarplicarecibeunmensajequenoenvi,lo
procesa como en el primer caso, sin requerir ninguna sincronizacin. En los dos
escenariosprevios,hayqueconsiderarlasituacinenqueunarplicaesexpulsada
del grupo mientras est procesando una peticin de servicio. En ese caso, los
threads que estn suspendidos deben desbloquearse, devolviendo alguna excepcin
alcliente.
ProcessGetNumberMessage()
getNumber()
castMessage al grupo
esperar a que se reciba
llamaraprocessGetNumberMessage()
guardarlastNumberGenerated
notificar que se haprocesado
devolverlacopia de lastNumberGenerated
processCastMessage()
si el mensaje es del tipo
GetNumberMessage,
A-Si esta instancia envi el mensaje,
1- notificar que se ha recibido.
2- esperar a que seprocese
B- En casocontrario,llamar a
getNumber()
castMessage al grupo
esperar a que se reciba
llamara processGetNumberMessage()
notificar quese ha procesado
devolverla copiade lastNumberGenerated
GetNumberMessage,
A-Siestainstancia envi el mensaje,
1- notificar que seharecibido.
2- esperar aque se procese
B- En caso contrario,llamara
getNumber()
castMessage algrupo
esperar aquesereciba
llamaraprocessGetNumberMessage()
devolverlacopiadelastNumberGenerated
GetNumberMessage,
A-Siestainstanciaenvi el mensaje,
1- notificar que seharecibido.
2- esperar aqueseprocese
B- Encasocontrario,llamara
Figura9.2.Alternativaparalasincronizacin delarespuesta
cliente
9.2.Transformacindeoperacionesenmensajes
En el ejemplo del anterior apartado se enva un mensaje en respuesta a la
peticin de operacin del cliente. Como ya se vio en el anterior captulo, sa es la
estrategia general: cada mensaje incluye la informacin necesaria para poder
ejecutar en cada rplica el mismo cdigo. Esta aproximacin implica definir un
mensajeparacadaoperacin,quedefinecomoatributoscadaunodelosparmetros
deentradadefinidosenlaoperacinasociada.
Es necesaria una extensin a lo descrito en el anterior captulo para permitir
que una misma rplica pueda procesar varias operaciones concurrentemente. Para
cadaunadeesasoperacionesseenvaunmensajeysuthreadasociadosebloquea
hastaqueelmensajeserecibaoseprocese.Porlotanto,esnecesarioasociarcada
mensaje al thread que lo enva, y por eso cada mensaje incluye una identidad
fcilmente asociable a ese thread. Usando JavaRMI, esta identidad podra ser
directamentelaasignadaporJavaalthread,peroenCORBAdebeserindependiente
del lenguaje de programacin final. Escogemos un valor entero para identificar al
thread, y el algoritmo deenvodemensajesybloqueodethreadsdebesercapazde
asignar a cada thread una identidad nica. Es importante notar que esta identidad
slotienesentidoparalarplicaqueenvaelmensaje,porloquesepuedeasignar
unamismaidentidadamensajesprovenientesdedistintasrplicas.
ConCORBA,todoslosparmetrosinyinoutdebenincluirseenelmensaje.La
operacin double obtainPercentage (in string key, inout long values, out boolean error)
setransformaenelmensaje:
valuetypeObtainPercentageMessage:Message
{
publiclongid;//identidaddelmensaje
publicstringkey;//parmetrodeentrada
publiclongvalues;//parmetrodeentrada
};
No es necesario incluir informacin de los parmetros de salida, pues no es
preciso que las dems rplicas devuelvan esa informacin. En el caso de JavaRMI,
todoslosparmetrossondeentrada,luegoelmensajeincluyetodoslosparmetros
6
delaoperacin.
Esta transformacin de operaciones en mensajes es fcilmente automatizable,
yunaherramientapuedegenerarlosmensajesnecesariosapartirdeladefinicinde
las interfaces. Este proceso de automatizacin es extensible al propio servidor
6
Que los parmetros sean de entrada, no implica que no puedan tratarse como parmetros de
salida. Por ejemplo, es posible enviar a un mtodo Java una instancia StringBuffer que nicamente se
emplee para devolver una cadena de caracteres. En este caso, no es necesario incluir el atributo
asociadoenladefinicindelmensaje.
replicado: es posible crear todo el cdigo y clases necesarias para definir un objeto
replicado a partir deladefinicindesuinterfazyunaimplementacinnoreplicada
deeseservidor.
Para entender esta automatizacin, partimos de una clase
NumberGeneratorImpl que implementa sin ningn soporte de replicacin la interfaz
NumberGenerator definida en el apartado anterior. El primer paso es la generacin
de un mensaje para la operacin getNumber. Este mensaje no contiene ningn
atributoasociadoalaoperacin,slolaidentidaddemensaje:
valuetypeGetNumberMessage:Message
{
publiclongid;
};
Se genera tambin una clase GroupNumberGeneratorImpl que implementa
igualmente la interfaz NumberGenerator e incluye todalalgicadegruponecesaria.
LalgicadeaplicacinsedelegaalainstanciadelaclaseNumberGeneratorImpl,con
loquelaoperacingetNumberresultaahoraenJava:
intgetNumber()throwsInvalidGroupException
{
intid=getRequestId();
Messagemessage=newGetNumberMessage(id);
castMessageAndBlockUntilReceived(message);
intret=theNumberGeneratorImpl.getNumber();
messageProcessed(id);
returnret;
}
Las operaciones en cursiva se explican posteriormente; este cdigo realiza los
siguientespasos:
Obtieneunaidentidadnicaparalaoperacinencurso.
Creaelmensajeasociadoalaoperacin,incluyendolaidentidadobtenida.
Envaelmensajealgrupoysebloqueahastaqueserecibaelmensaje.
Seinvocalaoperacinsobrelainstancianoreplicadadelservidor.
Se comunica que la operacin ha sido procesada, tal como se describi en el
anteriorapartado.
El valor devuelto por la instancia no replicada es el valor que se devuelve al
clientedelgrupo.
Elcdigoderecepcindelmensajesiguelaspautasdadasanteriormente:
voidprocessCastMessage(intsender,Messagemessage)
{
if(messageinstanceofGetNumberMessage){
GetNumberMessagemsg=(GetNumberMessage)message;
if(sender==myself){
unblockThreadAndWait(msg.id);
}
else{
theNumberGeneratorImpl.getNumber();
}
}
else
....
}
Severificacadaunodelostiposdemensajeesperado.
Silarplicaquerecibeelmensajeeslaqueloenvi,despiertaelthreadasociado
ysebloqueahastaqueesethreadconcluye.
En caso contrario, se invoca directamente la operacin sobre la instancia no
replicada. Si esta operacin precisa de parmetros de entrada, sus valores se
leendelmensajerecibido
7
.
Esta automatizacin emplea el segundo escenario descrito para la
sincronizacindelarespuestaenelanteriorapartado,inclusoparaoperacionesque
nodevuelvenvalores,puesesvlidoparatodotipodeoperaciones.
El cdigo descrito ha empleado cuatro primitivas, comunes para cualquier
servidor:
getRequestId: devuelve una identidad nica. Es fcilmente implementable a
partirdeunavariablecontipoenteroqueseincrementaconcadallamada.
castMessageAndBlockUntilReceived: enva el mensaje al grupo y bloquea al
threadquelollamahastaqueserecibaelmensaje.
unblockThreadAndWait: desbloquea al thread que tenga la identidad dada como
parmetroybloqueaautomticamentealthreadquelollama.
messageProcessed:desbloqueaalthreadasociadoalmensajeespecificado.
Esta automatizacin permite, por lo tanto, generar rpidamente un servidor
replicado apartirdeunainstancianoreplicadadeeseservidor.Elprocesodescrito
no es completo, ya que es necesario escribir manualmente el cdigo asociado a las
7
En C++, para los parmetros de salida deberan definirse variables temporales que se
descartaran tras invocarse la operacin. Lo mismo ocurrira en Javaparalosparmetrosmanualmente
excluidosdelmensaje,comoexpliclaanterioranotacin.
operacionesdetransferenciadeestado.EmpleandoJavaRMI,esposibleemplearsus
mecanismosdeserializacinparaimplementaresatransferencia,peroconCORBAla
implementacindeberealizarseindependientemente.
9.3.Comportamientonodeterminista
Apesardelosbeneficiosaparentesdelaautomatizacindescritaenlaseccin
previa, slo las aplicaciones ms sencillas podrn replicarse de esa manera. El
anterior enfoque implica replicar el comportamiento de la aplicacin a partir de su
interfaz.Perounainterfazdefinelasoperacionesasoportar,nolaimplementacino
estructuras de datos necesarias. Si en el ejemplo anteriorelgeneradordenmeros
nicosdebieradevolvernmerosaleatorios,suinterfazseraanlamisma:
interfaceNumberGenerator
{
longgetNumber();
};
Sin embargo, la implementacin pasa a considerarse no determinista: la
mismasecuenciadeeventosnoproducelamismasecuenciaderesultados.
Internamente, la aplicacin puede definir ahora una estructura de datos que
incluya todos los nmeros ya generados. Cuando se solicita un nuevo nmero, se
obtieneunoalazarysecompruebaenlaanteriorestructuradedatossiestlibreo
hasidoyaasignado;sinoloest,sepuedegenerarotroosimplementeiterarenla
tabla a partir del nmero anterior buscando el primer nmero libre. Esta tabla es
evidentementefinita,peroobviamosestehechoparalospropsitosdeesteejemplo.
Alnohabercambiadolainterfazidl,elprocesodeautomatizacinproducirael
mismo cdigo detallado en la seccin previa, lo que provocara resultados
incorrectos:
Cuando una rplica recibe la solicitud getNumber, enva el mensaje
GetNumberMessage.
Cada rplica, al recibir este mensaje, invoca la instancia no replicada del
servidor.
Las distintas rplicas, si el algoritmo de aleatoriedad es bueno, producirn
distintosnmerosaleatorios,conloquelaconsistenciadesusestadossepierde.
Distintas rplicas consideran que los nmeros asignados son distintos, con lo
queproducirneventualmentenmerosnonicos.
La solucin a este problema es sencilla: la rplica que recibe la solicitud
getNumbergeneradirectamenteunnmeroaleatorio,queesincluidoenelmensaje
GetNumberMessage.Losdemsmiembrosdelgrupocompruebansiesenmeroest
libre y, si no es as, iteran sobre su estructura de datos interna hasta obtener el
siguiente nmero libre, pues generar otro nmero aleatorio producira el mismo
resultado errneo. Pero a pesar de la sencillez de la solucin, el problema es ya
incompatibleconlaautomatizacindescrita.
Este problema no se asocia slo a comportamientos no deterministas. Si por
ejemploelservidordebeenviarelresultadodelaoperacinaunapginaWebo,en
general, actuar como cliente de un servidor diferente, slo una de las rplicas
deberaefectuarlaoperacincorrespondiente.Esteproblemaesinherentealservicio
detoleranciaafallosdeCORBA,comodetallamosalfinaldeestecaptulo(dehecho,
ese servicio especifica claramente que las aplicaciones soportadas deben ser
deterministas).
9.4.Replicacindecomponentes
Un comportamiento no determinista es uno de los casos que impiden la
automatizacinpropuestaenlareplicacindeunservidor.Otrocasoyasealadose
da cuando ese servidor debe acceder aciertosrecursosexternos;siporejemploun
servicio debe acceder a un servidor GPS que devuelve la posicin geogrfica de un
determinado localizador, y ese servidor cobra porcadaacceso,elservidorareplicar
deberaevitarquetodaslasrplicasconsultaranalservicioGPS.
Engeneral,todoservidorcuyaimplementacindependadeotrosservidoresno
podr automatizarse con el mtodo descrito. Y este problema persiste incluso si la
dependenciaseproduceaniveldeinterfaz.Porejemplo,laclasejava.util.Vectorque
implementa la interfaz java.util.List podra utilizarse para crear un contenedor
replicado; sin embargo, esta clase devuelve en algunas operaciones iteradores que
permiten observar los elementos contenidos en el Vector. Y esos iteradores deben
modificarse para soportar las caractersticas replicadas del contenedor asociado, lo
que implica modificar el cdigo que produce esos iteradores para crear los nuevos
consoportedereplicacin.
Por lo tanto, la automatizacin del proceso de replicacin es nicamente
aplicable a servidores sencillos. Por otra parte, es posible identificar estructuras en
el servidor que puedan replicarse automticamente. Volviendo al ejemplo del
generadordenmerosnicosyaleatorios,seidentificafcilmentecomoreplicablela
estructuradedatosinternaquecontienelosnmerosyagenerados.Estaestructura
seprogramaseparadamenteconlasiguienteinterfaz:
interfaceNumberSet
{
booleanset(inlongNumber);
};
La nica operacin definida, fija como asignado el nmero dado en el
parmetroydevuelvetruesielnmeroestabatodavalibre(noasignado).
El servidor no replicado se programa empleando una instancia de la interfaz
NumberSet, denominada theNumberSet en el siguiente cdigo, que debera ser
mejoradoparaunasituacinrealdondeelcontenedordenmerosnoesinfinito.No
obstante, muestra la idea del algoritmo: iterar sobre el contenedor hasta encontrar
unaposicinlibre,comenzandodesdeunaposicinaleatoria:
intgetNumber()
{
intinitial=getRandomNumber();
while(!theNumberSet.set(initial)){
++initial;
}
returninitial;
}
La interfaz NumberSet s es automticamente replicable, con lo que slo es
necesario cambiar el cdigo del servidor para instanciar y emplear la clase que
implementa el comportamiento replicado. Este servidor, al recibir una peticin
getNumber no se comunica con sus rplicas sino que ejecuta el mismo cdigo
empleado en el servidor no replicado. Sin embargo, cada vez que ahora accede a
theNumberSet emplea una estructura replicada que s se comunica con sus dems
rplicas.
Lafigura9.3muestraelcambiodeenfoquedeestaaproximacin:nosereplica
el servidor completo, sino los componentes que lo precisan. Los servidores forman
un grupo tolerante a fallos pero no interaccionan directamente entre ellos, sino a
Aplicacin
replicada
Figura9.3.Enfoque enlareplicacin decomponentes
Comunicaciones
ensincrona
virtual
Acceso del cliente
Componente
replicado
Comunicaciones
ensincrona
virtual
Aplicacin
Acceso del cliente
Aplicacin
Servidoressin
interaccinmutuadirecta
travsdeesoscomponentes.Laabstraccinqueesoscomponentesreplicadoscrean
esladeunnicocomponentecompartido(memoriacompartida).
9.5.Librerasdecomponentesreplicados
EllenguajeC++[ISO98,Stroustroup97]secreyextendiinicialmentesinuna
librera de contenedores, lo que provoc que cada programador diseara e
implementara sus propias soluciones para pilas, listas, rboles binarios, etc, o que
se adhiriera a determinadas soluciones comerciales, pocas veces compatibles entre
s. La estandarizacin posterior del lenguaje incluy una librera estndar de
templates (STL) [ISO98, Plauger95], simplificando considerablemente este escenario.
Un programador puede emplear distintas implementaciones sabiendo que son
compatibles, y usar la que produzca mejores rendimientos. El empleo de servicios
replicados est poco extendido a pesar de sus indudables beneficios. Ylacausano
esnicamenteelmenorrendimientoqueseconsigue,sinoladificultaddesudiseo.
Si se dispone de libreras de componentes replicados, ese diseo se facilitar
considerablemente.
El principal problema es entonces considerar qu componentes deben ser
replicados. En general, el comportamiento de una aplicacindependedelestadode
sus datos. Esto no implica un determinismo, que empleando los mismos datos esa
aplicacin produzca siempre los mismos resultados, pero s una consistencia de
stos. Consecuentemente, es comprensible enfocarse en los componentes que
almacenanesosdatos.
Cadaaplicacindefinesuspropiasestructurasdedatos,quepuedenserdesde
simpletiposexistentesenellenguaje,comoenteros,acomplejasestructuras,como
un rbol binario que contenga a su vez listas de valores enteros. Sin embargo, es
posible factorizar esas estructuras complejas en trminos de los contenedores
estndar.
El ejemplo mostrado en la seccin anterior podra simplificarse si
dispusiramosenJavadeunjava.util.Setreplicadoo,hablandoentrminosC++,de
un std::set replicado. Adems de la simplificacin que se obtiene en el diseo de
servidores replicados, la principal ventaja es la optimizacin que puede y debe
lograrse sobreesoscomponentes.SenseiUMAeslapartedeesteproyectoquetrata
eldiseodeestoscontenedoresreplicados.Estediseoestdirectamentebasadoen
lacoleccindecomponentesdisponiblesenJava1.2.
9.6.Soportedeconcurrencia
Alenfocarlareplicacinsobreloscomponentesdeunaaplicacin,esnecesario
estudiarlosproblemasdeconcurrenciaquepuedenaparecer.Enunaaplicacinno
replicada, el empleo de mltiples threads complica la implementacin de sus
componentes para soportar el acceso concurrente desde esos threads. En una
aplicacinbasadaencomponentesreplicados,esoscomponentespuedenentenderse
comoobjetoscompartidosalqueaccedenlasdistintosaplicacionesdelgrupo,porlo
quedebensoportardirectamenteunaccesoconcurrente.
Por ejemplo, la interfaz NumberSet utilizada en la seccin de replicacin de
componentes se dise de tal manera que permitiera acceso concurrente desde
varios servidores. Si se hubieran seguido las reglas generales para escribir buen
cdigo, que dictan la definicin de mltiples operaciones simples en lugar de
complicadasoperacionesmultifuncin[Maguire93],sehabrandefinidodosmtodos
claramentediferenciados:
interfaceNumberSet
{
voidset(inlongNumber);
booleantest(inlongNumber);
};
Unmtodocompruebasiunnmerohasidoasignado,yelotroloasigna.Sin
embargo, esta interfaz no podra haberse usado directamente para producir
componentes replicados: dos servidores podran comprobar simultneamente si un
mismo nmero estaba libre, obteniendo ambos una respuesta afirmativa y
asignndolo errneamente [figura 9.4]. Al juntar los dos mtodos, se obtiene una
operacinatmicaquesoportaaccesosconcurrentes.
Esta definicin de operaciones atmicas especficas no es posible al emplear
componentes genricos. En este ejemplo, el componente empleado sera un Set,
definido como un contenedor de elementos que no admite duplicados, o un BitSet,
definido como un contenedor numerado de valores booleanos. Basndonos en la
clase java.util.BitSet, seran necesarias las dos operaciones siguientes, expresadas
enJavacomo:
booleanget(intbitIndex);Devuelveelvalordelbitenelndicedado.
voidset(intbitIndex);Asignaalbitdadoelvalors/cierto/true.
Y tal como suceda con las operaciones de la interfaz previa NumberSet, se
observanlosmismosproblemasdeconcurrenciadescritos.Lasolucinenelcasode
acceso concurrente bajo mltiples threads es el empleo de monitores: un thread
debe adquirir un monitor antes de efectuar una operacin crtica, liberndolo al
concluirla. Distintos threadsaccedenalmismomonitor,loqueimpidequeejecuten
concurrentementelaoperacincrtica.
Por extensin, la solucin para el problema de concurrencia en componentes
replicadoseselempleodemonitoresreplicados.Estosmonitoresdebensoportardos
operaciones,conlassiguientessemnticas:
lock: adquisicin del monitor. Ante una adquisicin concurrente desde varias
rplicas, slo una lo obtiene. Las dems rplicas que pretendan adquirir ese
monitor quedan bloqueadas hasta que se libere el monitor o hasta que el
componentequelohaadquiridosecaigaoseaexcluidodelgrupo.Unavezqueel
monitor se libere, cualquiera de las rplicas bloqueadas puede obtenerlo,
pasando a estado no bloqueado. Una misma rplica puede adquirir un monitor
repetidasveces,esdecir,elmonitoresreentrante.
unlock: libera un monitor previamente adquirido, producindose un error si la
rplicanohabaadquiridoelmonitor.Siesarplicahubieraadquiridoelmonitor
mltiples veces, debe invocarse esta operacin el mismo nmero de veces para
liberarefectivamenteelmonitor,
Estasdosoperacionessonsuficientessinoseplanteancondicionesdeguarda
(wait/notify), necesarias normalmente en aplicaciones multithread cuando diversos
threadsdebencomunicarseentres.
Con esta definicin, una rplica que adquiere un monitor puede obtenerlo
repetidamente sin precisar liberarlo entre adquisiciones. Este monitor controla, de
esta manera, regiones crticas entre diferentes rplicas, pero no entre diferentes
threadsdeunamismarplica.
Empleando un monitor y un bitset replicados, el servidor NumberSet podra
codificarsecomo:
number=getRandomNumber();
replicatedMonitor.lock();
NumberSet
5:libre
5: asignado
Figura9.4.Problema deconcurrenciaenNumberSet
ServidorA ServidorB
NumberSet
5:libre
5:asignado
Contenedorreplicado
Nmero5libre?
Nmero5libre?
S
S
Asignarnmero 5 Asignarnmero 5
Devolver
5
Devolver
5
Error:ambos
servidoresdevuelven el5,
unonodevuelve un
nmeronico.
while(replicatedBitSet.get(number)){
number++;
}
replicatedBitSet.set(number);
replicatedMonitor.unlock();
returnnumber;
Este cdigo es completamente anlogo al empleado en una aplicacin
multithread; la diferencia existe slo en los objetos empleados que, al estar
replicados, puedenprovocarerroresensuscomunicacionesconlasdemsrplicas.
EstasituacinesparalelaalaexistenteencualquieraplicacinCORBA:elaccesoa
objetos remotos se realiza bajo la abstraccin de quesonlocalesylatransparencia
slo se pierde en el menor rendimiento obtenido y en la necesidad de verificar los
problemasdecomunicaciones.
9.7.Transferenciadeestado
Al promover la factorizacin de aplicaciones replicadas en componentes
replicados, el empleo de una interfaz de transferencia de estado flexible resulta
obviamente til. Sin soporte de transferencia de estado, cada componente debera
implementar sus propios protocolos y, si la interfaz de transferencia existente es
poco flexible, provocara una mala adaptacin de esos componentes que podra
redundarenunpobrerendimiento.Encualquiercaso,latransferenciadeestadoha
sido el tema central envarioscaptulosanteriores,conloquenoslimitamosaqua
exponerdenuevolanecesidaddeunsoporteflexibledetransferenciadeestado.
Un aspecto de los protocolos de transferencia que se expuso en los captulos
previos fue la necesidad de transferencias en varios pasos, especialmente tilenel
caso de estados grandes. Al factorizarse una aplicacin en componentes menores,
eserequisitoesannecesarioporvariasrazones:
Laaplicacinpuedeenviarelestadodetodossuscomponentesenunsolopasoo
aprovechar el protocolo para enviar el estado en sucesivos pasos, cada
componenteporseparado.
Un componente separado puede ser an suficientemente grande por s solo.
Tomando un contenedor como ejemplo, puede emplear sucesivos pasos para
transferir su estado cuando contiene muchos elementos, o transferirlo en un
nicopasoencasocontrario.
Como se vio anteriormente, un servidor no puede, en principio, procesar
mensajes de otras rplicas o de clientes mientras efecta una transferencia. En el
casodetransferenciasgrandes,esaprdidadeserviciopuedesernopermisible,con
lo que sera preciso que la aplicacin no se bloqueara y transmitiera su estado en
diferentes etapas, implementando algoritmos que le permitieran transferir los
cambios de estados producidos durante la transferencia en curso. Estos algoritmos
no son triviales, lo que supone otra ventaja para el argumento de emplear libreras
de componentes replicados, que implementan ya estos algoritmos de forma
optimizada.
9.8.Gestindecomponentesreplicados
El empleo de componentes replicados ha mostrado tres ventajas respecto a la
replicacinmonolticadelaaplicacin:
Mayor facilidad para automatizar su implementacin apartirdeuncomponente
noreplicado.
Minimizar el tiempo de desarrollo mediante reusabilidad de cdigo, al emplear
librerasconcomponentesreplicadosyadesarrollados,probadosyoptimizados.
Simplificacin del cdigo, al acceder a esos componentes replicados como
componentesestndar,noreplicados.
Sin embargo, estos componentes no son objetos normales, tienen un ciclo de
vida especial. Cada componente, una vez creado, debe acceder a un servicio GMS
paracrearungrupooincluirseenunoyaexistente.Ycadacomponentepertenecea
ungrupodistinto,conloquelaaplicacindebeesperaraquetodosloscomponentes
pertenezcanasusrespectivosgruposparapoderemplearlos.
Adems, como se vio en los anteriores captulos, un miembro puede ser
excluido de un grupo accidentalmente, en caso de que resulte lento o sus
comunicacionesconotrasrplicasseanlentas.Laexclusindeuncomponentedado
deentrelosmuchosqueunaaplicacinpuedecontenersupondrunamermatotalo
parcial de la disponibilidad de esa aplicacin. En este caso, es posible corregir esa
expulsinincluyendoalcomponentedenuevoenungrupo,perolascausasquehan
provocado su exclusin accidental implican que muy probablemente otros
componenteshabrnsidoexpulsadosigualmentedesusgrupos.Encualquiercaso,
laaplicacindebemanejarestoseventosyparareventualmentesuactividad.
Haydosaproximacionesenelempleodemltiplescomponentes.Laprimeraes
crear mltiples grupos, lo que implica la necesidad de coordinacin desde la
aplicacin. La segunda es crear un nico grupo donde cada componente aparece
como subgrupo. Para minimizar la confusin con grupos y subgrupos, llamaremos
dominio al grupo principal, que es el nico que debe emplear el GMS para crear o
incluirse en su grupo de rplicas, y componentes a esos subgrupos. Cuando un
componente se comunica con sus rplicas, el dominio incluye una identidad
asociadaaesesubgrupoenlosmensajes,detalformaqueeldominiodestinopueda
demultiplexarstosalcomponenteadecuado,comomuestralafigura9.5.
El modelo de dominios supone adems un empleo menor de recursos.
Empleando SenseiGMS, cada grupo crea su propio anillo, con un testigo
independiente;cadamiembrocompruebasuscomunicacionesconelgrupo,vigilala
prdidaoduplicacindeltestigo,etc.Siexisteunnicogrupo,selimitaeseempleo
de recursos. Adems se simplifica la interaccin entre rplicas, al no tener que
coordinarse los grupos de los distintos componentes; en su lugar, loscomponentes
son los subgrupos que deben subscribirse al dominio mediante una sencilla
operacin. El dominio slo debe asegurar que cada componente tenga la misma
identidadencadamiembrodeldominio.Elestadodeldominioloformanelestadode
esos componentes ms las propiedades asociadas al dominio, como son las
identidades de los componentes. Como el primer pasotraslainclusindeldominio
en su grupo es la transferencia de estado, la coherencia en la asignacin de
identidades a componentes en los miembros del dominiopuedecomprobarsedesde
un principio. Este razonamiento implica que los componentes se registran en el
dominioantesdequesteseunaasugrupo.
Para entender mejor el concepto, emplearemos un ejemplo de un servicio de
ficherosreplicado.Enesteservicio[figura9.6],loscomponentessonlosdirectoriosy
ficheros,dondelosdirectoriosagrupanficheroslgicamente.Todoslosmiembrosdel
dominio contienen los mismos directorios y ficheros, de tal formaqueelservicioes
tolerante a fallos. Cada uno de los componentes en este ejemplo se registra en el
dominio y la aplicacin incluye a continuacin el dominio en su grupo de rplicas.
Cuandoeldominiorecibelosmensajesdetransferenciadeestado,obtieneelestado
delosdirectoriosydelosficheros,ascomoinformacindelosotrosmiembrosenel
dominio. En particular, recibe la confirmacin de que todos los miembros han
definidolosmismoscomponentesconlasmismasidentidades.
Este ejemplo demuestra tambin la necesidad de dinamismo en el empleo de
componentes. El servidor mostrado no puede extender el nmero de ficheros que
Figura9.5.Empleo dedominios
Componente
id1
Componente
id2
Componente
id3
Componente
id4
Dominio
MensajeA
Componente
id1
Componente
id2
Componente
id3
Componente
id4
Dominio
MensajeA
MensajeA,
Componente id1
Componente
id1
Componente
id2
Componente
id3
Componente
id4
Dominio
MensajeA
sirve, puesto que los componentes deben ser conocidos antes de la inclusin en el
grupo,momentoenelquesepodraobtenerfcilmenteesainformacin.Adems,si
se pretende poder emplear componentes replicados sin diferenciarlos de otros
componentes normales en la aplicacin, es preciso que se puedan crear esos
componentes dinmicamente. Siguiendo con el escenario descrito, un cliente de la
aplicacinreplicadapodrasolicitarlacreacindeunnuevoficheroenundirectorio
dado: el servidor crea en este caso el componente que representa el fichero y le
asignaunaidentidad,comunicndoseloentoncesalasdemsrplicas.
Hay, por lo tanto, componentes estticos, que se registran antes de incluirse
enelgrupoderplicas,ycomponentesdinmicos,registradostraslainclusinenel
grupo. Todos los miembros del dominio deben registrar los mismos componentes
estticos,mientrasqueloscomponentesdinmicossoncreadosporunmiembrodel
dominio,propagndosesucreacinalosotrosmiembros.
Un dominio no es ms que un grupo que multiplexa/demultiplexa los
mensajes de sus componentes, pero define a su vez sus propios mensajes. La
creacindeuncomponentedinmicopuedeimplementarseentoncesapartirdeun
mensajeespecficodeldominio,incluyendoinformacinsobreelcomponentequese
crea. Este componente debe existir en el espacio de memoria de cada una de las
rplicas,porloquecuandoeldominiorecibeelmensajedecreacindelcomponente,
solicita a la aplicacin que cree dinmicamente ese componente con lainformacin
obtenida.Deesterequisitosededucequelaaplicacindebesoportarunaoperacin
callback para crear componentes dinmicamente. Por ejemplo, en Sensei este
mtodoes:
Dominio
Dominio
Fichero file.4
(componentec5)
Fichero file.5
(componentec6)
Directorio dir.B
(componentec4)
Fichero file.4
(componentec5)
Fichero file.5
(componentec6)
Directorio dir.B
(componentec4)
Fichero file.4
(componentec6)
Fichero file.5
(componentec7)
Directorio dir.B
(componentec5)
Fichero file.1
(componentec2)
Fichero file.2
(componentec3)
Fichero file.3
(componentec4)
Directorio dir.A
(componentec1)
Fichero file.1
(componentec2)
Fichero file.2
(componentec3)
Fichero file.3
(componentec4)
Directorio dir.A
(componentec1)
Fichero file.1
(componentec2)
Fichero file.2
(componentec3)
Fichero file.3
(componentec4)
Directorio dir.A
(componentec1)
Figura9.6.Servicioreplicadodeficheros
Dominio
GroupMembersubgroupCreated( inGroupMemberIdcreator,inSubgroupIdid,
inDynamicSubgroupInfoinfo);
Se recibe la identidad dada al componente e informacin sobre el tipo de
componente,talcomolahayadadolarplicaquelocre.
Durante el proceso de transferencia de estado, un dominio que se incluye en
un grupo recibe informacin sobre los grupos dinmicos ya creados, de tal forma
que pueda crearlos en su espacio de memoria antes de recibir el estadoasociadoa
esos componentes. Es tambin posible eliminar componentes dinmicos, lo que se
traduceenotromensajedeldominioyenlanecesidaddeotromtodocallbackenla
aplicacin.Sinembargo,noesposibleeliminarloscomponentesestticos,puessu
existencia se verifica con cada transferencia de estado. Introducir estas diferencias
entre ambos tipos de componentes puede parecer una complicacin, teniendo en
cuenta, adems, que los dinmicos son ms flexibles que los estticos, pero las
aplicaciones replicadas que precisen nicamente de componentes estticos se
benefician de no tener que soportar la funcionalidad adicional necesaria por los
dinmicos.
Que las identidades de los componentes sean nicas implicar generalmente
una necesidad de comunicaciones en el dominio para consensuar la unicidad de
cadaidentidad.Porestarazn,eselmismodominioelquegeneralasidentidadesen
caso de componentes dinmicos. Esta es la otra diferencia con los componentes
estticos;cuandostosseregistran,eldominioannoperteneceaungrupo,conlo
que no puede comunicarse con otros miembros, lo cual deja tres opciones para la
obtencindeidentidades:
Las identidades son asignadas secuencialmente segn se registran los
componentes. Todos los dominios deben registrar entonces en esemismoorden
todos sus componentes estticos, lo que puede originar problemas en caso de
aplicacionesmultithread.
Lasidentidadessondadasporlaaplicacinalregistrarelcomponenteesttico.
La asignacin de identidades se pospone hasta la insercin del dominio en un
grupo: complica la aplicacin y los componentes, que deben implementar la
funcionalidad necesaria para recibir esa informacin. Adems, si esa asignacin
se produce siguiendo el orden en que se registraron los componentes, se da el
mismoproblemaqueconlaprimeraopcin.
Por estos motivos, es la aplicacin la que define las identidades de los
componentes estticos y el dominio el quelasasignaparacomponentesdinmicos.
Debe notarse que, sin el concepto dado de dominios, el empleo de componentes
dinmicos es tambin posible cuando cada componente emplea su propio grupo de
rplicas.Enestecasolaaplicacindebedefinirotrogrupoespecialparamanejarlos
mensajesparalacreacinydestruccindeesoscomponentes.
Volviendo al ejemplo dado de servidores replicados de ficheros, su
implementacin puede realizarse ahora empleando nicamente componentes
dinmicos. Sin embargo, si la estructura de ficheros es jerrquica, eldirectorioraz
siempre estar presente, lo que da sentido a tener un nico componente esttico
asociadoaesedirectorio.Cuandoesteservidorrecibeunapeticindecreacindeun
fichero,creaelcomponenteasociado:
publicFileDescriptorcreateFile(Stringname,DirectoryDescriptordescriptor)
throwsDirectoryNotExisting,FileAlreadyExists
{
Directorydir=getDirectory(descriptor);
if(dir.contains(name)){
thrownewFileAlreadyExists();
}
Filefile=newFile(domain,name,descriptor);
dir.add(file);
returnfile.getDescriptor();
}
Aunque este cdigo resulta muy similar al de un servidor no replicado, la
primera diferencia se da ya en el constructorparaelcomponenteFile,quenecesita
dos parmetros adicionales: el dominio, donde debe registrarse, y el descriptor del
directorio,puesestainformacindebepropagarsealasdemsrplicas:
File(Domaindomain,Stringname,DirectoryDescriptordescriptor)
{
DynamicSubgroupInfoinfo=newFileInfo(name,descriptor);
subgroupId=domain.createSubgroup(info,this);
}
Cuando el dominio crea el subgrupo, enva un mensaje a las dems rplicas
del dominio, y slo lo considera creado cuando ese mensaje es procesado,
asignndoleentoncesunaidentidadnica.Cadarplicadebesuministrarsupropio
callbackparacrearelcomponente:
GroupMembersubgroupCreated(intcreator,intid,DynamicSubgroupInfoinfo)
{
if(infoinstanceofFileInfo){
FileInfofileInfo=(FileInfo)info;
Filefile=newFile(id,info.name);
Directorydir=getDirectory(descriptor);
dir.add(file);
returnfile;
}
...
}
Enestecdigo,quenoincluyecondicionesdeerror,laaplicacindecideeltipo
de componente a crear en funcin de la informacin recibida. El constructor
empleadoparaelcomponentequerepresentaelficheroesdiferentealqueseemple
anteriormente:ahoranoprecisaregistrarseeneldominio,puesyaloest,recibesu
identidad asociada, que ya es conocida, y no precisa recibir el directorio en que se
encuentra,puesesainformacinesredundanteparaelcomponentefichero.
El empleo de componentes dinmicos es entonces ms complicado, con la
necesidaddefuncionalidadenlaaplicacinparacrearcomponentesendemanda,y
enloscomponentesparasoportardiferentesconstructoresconcadaescenario.
9.9.Transacciones
Los monitores replicados se han definido de forma similar a los monitores
empleados en aplicaciones multithread pues solucionan un problema tambin
similar: secuencializar el acceso concurrente a un componente o regin crtica de
cdigoparaevitaractualizacionesparalelasincompatibles.
Sinembargo,laconcurrenciaencomponentesreplicadosimplicaunproblema
adicional que no se asocia a aplicaciones multithread, sino a bases de datos
distribuidas:esprecisosincronizarelaccesoalabasededatosparaimpedirquedos
aplicacioneslaactualicendeformaincompatible.Adems,esnecesarioprotegerala
base de datos en caso de que una aplicacin se caiga sin haber completado sus
modificaciones.Lasolucinaesteproblemaeselempleodetransacciones[Gray93].
En el caso de una aplicacin que deba actualizar varios componentes
replicadosdeformacoordinada,sucada,oexpulsinaccidentaldelgrupo,antesde
completar todos los cambios conlleva una inconsistencia en el estado de esos
componentes.Esnecesario,entonces,unmecanismoqueprotejaaloscomponentes
replicadosdecadasdelasaplicacionescuandostasrealizanactualizacionessobre
varios componentes simultneamente. Este mecanismo lo llamamos, por
paralelismo,transaccin.
Empleandoelejemplodelservicioreplicadodeficheros,laoperacindemover
un fichero a un directorio distinto podra escribirse de la siguiente manera, sin
detallarcmocomenzarofinalizarlatransaccin:
voidmoveFile(Stringname,DirectoryDescriptororigin,DirectoryDescriptortarget)
throwsDirectoryNotExisting,FileNotExistingFileAlreadyExists
{
DirectorydirOrigin=getDirectory(origin);
DirectorydirTarget=getDirectory(target);
Filefile=dirOrigin.get(name);
Starttransaction
dirOrigin.remove(file);
dirTarget.add(file);
Endtransaction
}
La transaccin es necesaria para evitar que, si la aplicacin caetrasborrarel
ficherodelprimerdirectorioperoantesdeincluirloenelsegundo,elresultadoseala
prdidadeesefichero.
El mecanismo de transacciones puede basarse en componentes que incluyan
su soporte directamente: deben ser capaces de deshacer, no slo el ltimo cambio
efectuado, sino todos los cambios realizados desde el momento en que se inici la
transaccin. Evidentemente, este soporte puede resultar muy complicado de
implementar. Adems, se complica el empleo de esos componentes, que deben
recibir informacin sobre la transaccin en curso; as, el bloque anterior de cdigo
relativoalatransaccinpodraescribirsecomo:
...
Transactiontransaction=startTransaction();
dirOrigin.remove(file,transaction);
dirTarget.add(file,transaction);
endTransaction(transaction);
...
Es decir, las operaciones sobre el componente incluyen la informacin de la
transaccin. Lo que significa que la aplicacin debe emplear transacciones incluso
paraactualizacionesquenolasprecisan,comoeselcasoenqueafectanaunnico
componente. O bien, es necesario duplicar el nmero de operaciones en el
componente, con y sin soporte de transacciones, complicando an ms ese
componente.
Unaposibilidadalternativasebasaenlimitarloscambiosenloscomponentes
a la rplica que realiza la transaccin, hacindolos visibles a las dems rplicas
cuandolatransaccinsecompleta.Comolasoperacionessobreloscomponentesse
traducenenmensajesalgrupo,estasolucinimplicaencolaresosmensajesdurante
la transaccin. Esos mensajes deben, sin embargo, ser recibidos por la rplica que
realiza la transaccin, que s debe ser capaz de observar los cambios efectuados.
Este bloqueo de mensajes es fcil de realizar al emplear el concepto de dominios
explicadoenlaseccinanterior:puestoquetodoslosmensajessonmultiplexadosa
travs del dominio, es simple encolarlos a este nivel, mientras que si cada
componente definiera su propio grupo, cada componente sera responsable de
realizaresebloqueo.Elcdigorelativoalatransaccinsetransformaahoraen:
...
domain.startTransaction();
domain.endTransaction();
...
Yelusodelatransaccinresultatransparenteparaloscomponentes.
Hay dos problemas con esta solucin por sus implicaciones con el modelo de
sincrona virtual. El primero es que no todos los miembros del grupo observan los
mismosmensajesenelmismoorden.Siotromiembroenvaunmensajedurantela
transaccin, la rplica que realiza esa transaccin observa ese mensaje entre los
dems mensajes que la rplica est enviando, pues no hay un bloqueo de los
mensajes que se reciben. Sin embargo, las dems rplicas ven primero el mensaje
dadoyluegotodoslosmensajesdelatransaccin,enviadoscuandohafinalizado.
Por otro lado, el grupo podra instalar una nueva vista mientras un miembro
efectaunatransaccin,loquepresentatresopciones:
Posponer la instalacin de la nueva vista hasta que la transaccin se complete.
Pero la transaccin es un mecanismo lgico implementado sobre el GMS, que
entoncesdeberaserextendidoparaconocerelestadodelastransacciones.Esto
implicara un cambio muy importante, principalmente por la necesidad de
redefinir el comportamiento del GMS (especialmente la deteccin de miembros
cados).
Cancelarlatransaccin,quelaaplicacindebereiniciarunavezqueseinstalala
vista.Implicavolveraescribirlalgicadetratamientodevistasenlaaplicacin,
rompiendo la transparencia que se logra con el empleo de componentes
replicados. Adems, los componentes en la rplica que realiza la transaccin
deberndeshacerloscambiosefectuadoshastaelmomento,solucinquehemos
descartadoporcompleja.
Instalarlavistaycompletarlatransaccinenlasiguientevista.Estasolucines
la ms viable, pero presenta una nueva incompatibilidad con el modelo de
sincrona virtual: todos los miembros del grupo no observarn los mismos
mensajesentredosvistasconsecutivas.Elmiembroquerealizalatransaccinve
losmensajesenlavistaqueseenvan,mientrasquesusrplicaslosrecibenen
lavistaenqueconcluyelatransaccin.
Por consiguiente, esta segunda implementacin de las transacciones implica
unamenorcomplejidaddeloscomponentesydesuempleo,peroviolaelmodelode
sincrona virtual. Sin embargo, como el correcto uso de las transacciones, tal como
ocurreconenlasbasesdedatosoconlosmonitoresenlasaplicacionesmultithread,
dependedelaaplicacin,stapuedeescogercundoesaviolacinespermisible.
Este argumento se basa en el cambio de enfoque realizado: la aplicacin se
basa ahoraencomponentesreplicados,sinprecisarunconocimientodedetallesde
bajo nivel como es el cambio de vistas. La actualizacin del componente directorio
que contiene las referencias a unos componentes fichero no se ve influida por el
cambio en la composicin del grupo de rplicas de ese componente directorio o
componentes fichero, en tanto la actualizacin se realice apropiadamente en todos
los componentes y las nuevas rplicas que se incluyan reciban un estado
consistente.
As,siunmiembroiniciaunatransaccinyrecibedurantestaunmensajede
otro miembro, la aplicacin debe haber sido programada de tal manera que ese
mensajenoafectealatransaccin.Latransaccinencierra,porlotanto,unaregin
crticadecdigo,perostaesunaresponsabilidaddelosmonitoresyresultalgico,
consecuentemente,implementarlastransaccionesconmonitores:
...
domain.startTransaction(monitor);
...
Eliniciodelatransaccinimplicalaadquisicindelmonitorespecificado,que
esliberadocuandolatransaccinfinaliza.Sielmonitornoestlibre,latransaccin
nopuedecomenzar.
Siguiendoconelmismoejemplo,sielmensajequelaaplicacinrecibedurante
estatransaccineselcorrespondienteaunaoperacinderenombradodeunfichero
tal como dirTarget.rename(file, newName), implica que la aplicacin no ha
protegidocorrectamentelaactualizacindelrecursodirTargetconunmonitor,pues
permite que dos rplicas modifiquen concurrentemente ese mismo recurso. En
condicionesnormales,lasdosrplicasdeberanhaberescritouncdigosimilara:
RplicaA RplicaB
... ...
monitorTarget.lock(); monitorTarget.lock();
domain.startTransaction(monitorOrigin);
dirTarget.add(file); dirTarget.rename(file,newName);
monitorTarget.unlock(); monitorTarget.unlock();
... ...
En estas condiciones, la rplica B no hubiera podido enviar el mensaje dado,
pues estara bloqueada esperando a adquirir el monitor asociado al directorio
destino (o sera la rplica A la bloqueada). Los nicos mensajes que la rplica A
puede recibir, siempre y cuando la aplicacin se programe adecuadamente, son
aquellosquenoafectenalresultadodelatransaccinencurso:mensajesrelativosa
componentes no actualizados durante la transaccin o mensajes que no actualicen
componentes.
Es el mismo razonamiento empleado en el modelo de sincrona virtual. Este
modelo permite la inclusin o expulsin dinmica de miembros, pero los miembros
que pertenecen al grupo deben recibir los mismos mensajes en el mismo orden.
Posteriormente, ese requisito de orden total puede reducirse y emplear rdenes
menos restrictivos, siempre que una rplica sea incapaz de detectar sus
inconsistenciasdeestadoconotrasrplicas:siestacondicinsecumple,losclientes
de esas rplicas tampoco podrn observar las inconsistencias. Al emplear
transacciones, el orden se altera y la consistencia entre miembros est slo
aseguradaenlosmomentosdondenohayatransacciones,siendoresponsabilidadde
laaplicacinelocultaresasinconsistenciastemporales.
Sinembargo,lareplicacindeunaaplicacinespecficapuedeanrequerirel
empleodeordentotalcausalycomportamientodinmicouniforme:siunarplicaha
efectuado una determinada operacin, las dems rplicas la deben efectuar
igualmente, incluso si la primera ha cado. Si esa operacin se realiza bajo una
transaccin, los dems miembros no tendrn ninguna informacin de las
operaciones efectuadas si el miembro se cae antes de finalizarla, pues sa es la
finalidadbuscada.Comoconsecuencia,estetipodeaplicacionesnoadmiteelempleo
detransacciones.
Las bases de datos permiten tres operaciones bsicas con transacciones:
iniciarlas, completarlas y abortarlas. Adems, soportan transacciones anidadas
[Moss85]. La segunda solucin para las transacciones tiene un inconveniente con
respecto a la primera planteada, basada en componentes capaces de deshacer sus
cambios:unarplicanopuedeabortarunatransaccin.
La posibilidad de anidar transacciones es, por otra parte, muy conveniente;
como cada transaccin se realiza en torno a un monitor, implica, primero, la
adquisicindenuevosmonitoresy,segundo,elbloqueodelosmensajesentantola
ltima transaccin no haya finalizado. Puesto que los monitores replicados se han
definido como reentrantes, no es un problema emplear para una transaccin
anidadaunmonitoryaadquiridoenunatransaccinexterna.
Por otro lado, que una transaccin bloquee los mensajesenlarplicaquelos
enva,implicaunproblemaconelempleodemonitores:losdemsmiembrosdeben
saber que ese monitor ha sido adquirido, o podran adquirirlo simultneamente.
Pero si esa adquisicin del monitor precisa de comunicaciones con el grupo, no es
posible su empleo durante las transacciones, lo que impide, a su vez, el empleo de
transaccionesanidadas.staeslaraznporlaqueelltimolistadodecdigonose
escribicomo:
RplicaA RplicaB
... ...
domain.startTransaction(monitorOrigin);
monitorTarget.lock(); monitorTarget.lock();
dirTarget.add(file); dirTarget.rename(file,newName);
monitorTarget.unlock(); monitorTarget.unlock();
...
El monitor monitorTarget es obtenido durante la transaccin, perolarplicaB
slo recibe informacin de esa adquisicin tras concluir la transferencia, cuando
recibe a su vez informacin de su liberacin. Al desconocer esa adquisicin, ha
podido realizar una actualizacin inconsistente sobre un recurso con acceso
supuestamenteexclusivo.
En la transferencia de estado se bloquean todos los mensajes entrantes en
tantolatransferenciaserealiza,perolaaplicacinpuedemejorarelrendimientode
la aplicacin definiendo mensajes que pueden pasar ese bloqueo. De la misma
forma, la aplicacin puede definir mensajes que no son bloqueados durante la
transaccin,deformaquepuedanemplearselosescenariospreviamentedescritos.
Las dos operaciones soportadas por un monitor replicado, lock y unlock,
implican la definicin de dos mensajes. El mensaje asociado a lock no debe ser
bloqueado durante transacciones y es recibido por todos los miembros. Unmonitor
replicado est programado para reaccionar correctamente a la cada del miembro
que lo posee, por lo que su exclusin de la transaccin no implica posibles
inconsistencias. El mensaje asociado a unlock s debe ser bloqueado durante la
transaccin;encasocontrario,elmiembropodrarealizar,protegidoporunmonitor,
una serie de cambios sobre uno o ms componentes, y otra rplica, al adquirir el
monitor liberado, realizar cambios incompatibles con los del primer miembro, que
an no ha finalizado su transaccin y, por consiguiente, no ha hecho pblicos sus
cambiosefectuados.
Esta solucin al problema implica que los mensajes enviados en el dominio
debentenerunapropiedadqueprecisesucomportamientoantetransacciones,dela
misma forma que es necesaria otra propiedad para su comportamiento ante una
transferenciadeestado.
Hay, precisamente, una interaccin importante entre transacciones y
transferencia de estado: una rplica no debe coordinar una transferencia de estado
en tanto no complete todas sus transacciones en curso. Este razonamiento se
explica con la figura 9.7, donde una rplica inicia una transaccin y, antes de
concluirla, recibe unavistaconunnuevomiembroalquedebecoordinar.Antesde
recibirlavista,larplicaenvaunmensajem1algrupo,quelatransaccinbloquea;
sinembargo,larplicaprocesaesemensaje,actualizandoelestadodelcomponente
C, que pasa a tener un estado {m1}. Si la transaccin no impide la transferencia,
enva inmediatamente su estado al nuevo miembro (en un mensaje que no se
bloquea por la transaccin), que recibe por tanto ese componente C con su estado
actual,{m1}.Acontinuacin,larplicacontinasutransaccin,yenvaunsegundo
mensajem2,tambinbloqueado,queactualizaelestadodeCa{m1,m2}.Alfinalizar
latransaccin,elnuevomiembrorecibelosmensajesquehansidoencolados:m1y
m2.Siprocesaambosmensajes,suestadopasaaser{m1,m1,m2},inconsistentecon
el del grupo salvo que m1 sea idempotente. En caso contrario, debe obtener
informacin adicional para ser capaz de descartar el mensaje m1. El escenario se
complicaanmsalconsiderarquelarplicaentransaccinpuedetambinenviar
mensajesquelatransaccinnobloquea.
Es posible complicar los mecanismos de transferencia de estado para
solucionaresteescenario,incluyendociertainformacinadicionalenlosmensajeso,
por ejemplo, bloqueando el mensaje de transferencia de estado durante la
transaccin. Pero impedir que un miembro que procesa una transaccin sea el
coordinador de una transferencia resulta adems conveniente. Una transaccin
implicalaadquisicindeunmonitor,yunarplicaqueadquiereunmonitorbloquea
a otras rplicas, por lo que resulta apropiado que un miembro en transaccin (o
simplemente poseyendo un monitor) no sea escogido como coordinador de una
transferencia,oretrasestaentantolafinaliza.
Una consecuencia de definir un mensaje como no transaccionable es que
tampocopuedeserbloqueadoduranteunatransferenciadeestado.Paracomprobar
esta afirmacin, suponemos un caso donde un miembro del grupo est realizando
una transferencia y un nuevo miembro se incluye en este mismogrupo.Aunquela
transferencia no se inicia hasta finalizar la transaccin, ambos miembros deben ya
bloquearlosmensajesdelgrupo.Uncomponentedadodeestemiembrohadefinido
un mensaje especfico como no transaccionable y lo enva al grupo, sin que este
envo sea bloqueado; sin embargo, el mensaje no est definido como no bloqueable
durantelastransferencias,conloquenialcanzaalnuevomiembro,queloencola,ni
puede ser procesado por este miembro, que no puede entonces evolucionar en su
transaccin.
Figura9.7.Interaccinentretransaccionesytransferenciadeestado
Rplicaentransaccin
mensaje m1
Losmensajes entransaccin
sonencolados
C
m1
Nuevavistapornuevomiembro
mensaje deestado,noencolado
C
m1
mensaje m2
C
m1 m2
Finaldelatransaccin
mensajesencolados:m1,m2
C
m1 m2
m1
Inconsistencia:el nuevomiembro
nodeberahaberprocesadom1
Consecuentemente, la definicin de un mensaje como no transaccionable
implica que el componente que lo emplea debe ser capaz de construir su estado
aunque reciba mensajes en desorden (los bloqueados y no bloqueados en
transferencia se reciben en distinto orden), lo que complica sus algoritmos de
transferencia. De los componentes definidos en SenseiUMA, ninguno hace uso de
estetipodemensajes,limitndose,demomento,suempleoalosmonitores.
Finalmente, existe un efecto lateral asociado al bloqueo de mensajes durante
lastransacciones:puestoquelosmensajesnosonenviadoshastalafinalizacinde
la transaccin, se mejora el rendimiento de la aplicacin. Cada operacin sobre un
componente se traduce, siguiendo las primeras secciones de este captulo, en un
mensaje al grupo y el bloqueo de la rplica en tanto el mensaje se recibe y se
procesa. Bajo una transaccin, esos bloqueos son resueltos inmediatamente,
resultando en un cdigo ms rpido. Adems, puesto que todos los mensajes son
enviados al finalizar la transaccin, se obtiene un beneficio adicional, pues los
sistemas de comunicaciones fiables en grupo, incluido SenseiGMS, tienen un
rendimientomejorcuandounarplicaenvasucesivosmensajes:lafiabilidaddelas
comunicaciones precisa que los mensajes sean enviados y confirmados (y
descartados, segn el sistema), pero el envo de un segundo mensaje implica la
confirmacin del anterior, ahorrndose el sistema un paso del protocolo.
Dependiendo del tamao de cada mensaje, es tambin posible agrupar los
correspondientes alatransaccinenunnicomensaje,queesluegodivididoenel
dominiodistinto.
9.9.1.Transaccionesyelmodelodesincronavirtual
ElmodelodecomponentesdesarrolladoenSenseisobreelmodelodesincrona
virtual ha impuesto la necesidad de transacciones para mantener la coherencia de
los datos en caso de cadas. Sin embargo, las relaciones entre el modelo de
transacciones y el modelo de sincrona virtual han sido ya ampliamenteestudiadas
con anterioridad, pues ambos modelos sirven, independientemente, para el mismo
fin:laconstruccindeaplicacionesfiables.
Tanto los algoritmos de transacciones, como los empleados para las
comunicacionesmultipuntoenelmodelosincronavirtual,debenresolverproblemas
deconsenso.Sehademostradoqueexisteunmecanismobsico,DT-multicast,conel
que se pueden construir ambos modelos [Guerraoui95], partiendo de una
implementacindelprotocolodecompromiso(commitprotocol).
Sin embargo, la integracin de ambos modelos se ha realizado normalmente
mediante la implementacin de uno sobre el otro. Por ejemplo, puesto que un
mensaje fiable multipunto tiene por s mismo semnticas transaccionales
[Schiper96], es posible obtener la atomicidad requerida para una transaccin
encapsulndola en un nico mensaje fiable multipunto. La propuesta de
implementacindetransaccionesenSenseiDomainsempleaestemismoenfoque.
Es ms habitual emplear el modelo de sincrona virtual para incrementar la
disponibilidad de sistemas basados en transacciones. En este caso, el sistema est
basadoentransaccionesyelmodelodesincronavirtualquedageneralmenteoculto.
Unaopcin[Little00]esquelastransaccionesseefectensobresistemasreplicados,
pero el principal inconveniente es que cada una de las rplicas debe procesarcada
transaccin,inclusoaquellasquenosecompletanydebenabortarse.Seobtieneun
mejor rendimiento cuando los cambios se realizan sobre una nica rplica que, a
continuacin, los propaga a las otras rplicas [Patio00]; la transaccin todava
puedeabortarse,encasodecolisinconotrastransacciones.
SenseiDomains tambin procesa cada transaccin en una nica rplica,
propagando los cambios al final, pero el enfoque es radicalmente diferente.
SenseiDomains no es un sistema basado entransacciones,sinounsistemabasado
en el modelo de sincrona virtual que soporta un mecanismo similar a las
transaccionesparapreservarlaconsistenciadevarioscomponentesencasodecada
deunarplica.
Una transaccin debe verificar cuatro propiedades, denominadas ACID por su
denominacin en idioma ingls: Atomicidad (Atomicity), consistencia (Consistency),
aislamiento (Isolation) y persistencia (Durability). Una transaccin, o se completa y
los cambios efectuados no se pierden incluso ante fallos o cadas, o se aborta, en
cuyo caso el estado del sistema es el que tuviera antes de que se efectuara la
transaccin.Lapropiedaddeaislamientoimplicaquelastransaccionesconcurrentes
no observan los cambios que se producen en otras transferencias hasta que se
completan,yestapropiedadnoseverificaenSenseiDomainsparalastransacciones
anidadasnilasconcurrentesiniciadasporunamismarplica.
En SenseiDomains, una transaccin protege exclusivamente sobre cadas en
un miembro y no es el mecanismo bsico para obtener fiabilidad. Por esta razn,
aislarloscambiosproducidosportransaccionesiniciadasporunamismarplicano
conlleva ningn beneficio al modelo, donde el empleo de las transacciones es
totalmente transparente para la rplica que las efecta (si una transaccin no
observaloscambiosqueseproducenenotra,estatransparenciasepierde).
Adems,laconcurrenciadelastransaccionesnoestampocounaprioridad;un
sistema basado en transacciones busca optimizar esta concurrencia, de tal forma
que puedan procesarse tantas transacciones concurrentes como sea posible. Los
mecanismos de control de concurrencia se clasifican comopesimistasuoptimistas,
y el empleo de monitores, aun siendo el ms habitualmente empleado, entra en el
grupo de mecanismos pesimistas. Sin embargo, hay varios tipos de monitores y los
empleados en SenseiDomains son de lectura/escritura, considerados los menos
concurrentes.Otrossistemasbasadosentransacciones,comoTransLib[Jimnez99],
emplean monitores basados en conmutacin, donde es posible definir las
condiciones que permiten conmutar dos operaciones y procesarlas
concurrentemente.Porejemplo,conunmonitordelectura/escritura,unaoperacin
de creacin de un fichero en un directorio no es concurrente con ninguna otra
operacindemodificacindeesedirectorio;conunmonitorbasadoenconmutacin
de operaciones, es posible crear un fichero y borrar simultneamente otro, siempre
quenotenganelmismonombre.
9.10.ComparacinconelmodelodeCORBA
Como se expuso en captulos anteriores, el servicio de tolerancia a fallos de
CORBAsoportareplicacinactivaypasivay,dentrodelapasiva,diferentesopciones
de backup. En todos los casos la aplicacin se programa bajo un mismo modelo, lo
que permite cambiar el tipo de replicacin sin modificar la aplicacin, al menos
tericamente.
Esta filosofa implica que las rplicas se programan sin ningn conocimiento
de las otras rplicas (aunque pueden obtener esa informacin) y es el servicio el
encargado de emplear el modelo de sincrona virtual e implementarlo
transparentementeparalasrplicas.
La figura 9.8 muestra el modelo empleado en este servicio CORBA. Su
especificacin incluye la posibilidad de que el modelo de sincrona virtual que
sustenta las operaciones en grupo se implemente por debajo del ORB, para as
obtener un mejor rendimiento. En este caso, la peticin del cliente es recibida
directamente por este sistema de comunicaciones, que la enva a los dems
miembros del grupo. Este sistema ordena todas las comunicaciones al grupo,
Figura9.8.Modelo del serviciodetoleranciaafallos CORBA
Cliente
Sistemadecomunicaciones en
grupobajosincrona virtual
Sistemadecomunicaciones en
grupobajosincrona virtual
ORB ORB
Servidor
Slocdigode
proceso de
peticin
ORB
Servidor
Slocdigode
proceso de
peticin
envindolas secuencialmente a las rplicas. Lasrplicasnoprecisanincluirningn
cdigodegrupo,sloelcdigodeprocesadodelaspeticionesdelosclientes.
Por otra parte, la figura 9.9 muestra de forma esquemtica el modelo de
sincronizacinexpuestoenestecaptulo:elclienteaccedeaunservidor,queincluye
internamenteelcdigoparacomunicarasusrplicaslaoperacinencurso,quese
procesa en orden total con respecto a las dems operaciones que el grupo est
realizando.Esposiblediferenciarelcdigoqueprocesarealmentelapeticin,similar
o igual al que precisara el servidor si no estuviera replicado, del cdigo empleado
paramantenerlaconsistenciaenelgrupo.
Ambos modelos son muy similares, pero el servicio CORBA oculta todas las
comunicacionesalgrupo,loquepermiteundiseodelasrplicasmuysimplificado.
Enprincipio,lanicadiferenciaentreunservidornoreplicadoyotroqueloest,es
el soporte de las primitivas de transferencia de estado. Sin embargo, esta
simplificacinsuponeimportantesinconvenientes.
El primer problema que presenta es la imposibilidad de optimizar las
comunicaciones. Un importante nmero de operaciones en todo servidor lo
constituyen las operaciones de consulta, que no actualizan su estado. Estas
operacionesnoprecisancomunicarsealgrupoypuedenprocesarseinmediatamente.
BajoCORBA,estaoptimizacinnoesinicialmenteposible;unaposibilidadseraque
esasoperacionessedefinieranenlainterfazIDLapartirdeatributosdeslolectura,
que se traducen en operaciones de lectura de ese atributo. Sin embargo, la
especificacin CORBA no incluye la limitacin de que estas operaciones nopuedan
Comunicacionesen
sincronavirtual
Servidor
Servidor Servidor
Figura9.9.Esquema simpledelasincronizacin delarespuesta
Cliente
Cdigodegrupo
Cdigodeproceso
depeticin
Cdigodegrupo
Cdigodeproceso
depeticin
Cdigodegrupo
Cdigodeproceso
depeticin
actualizar el estado del servidor, por lo que sera preciso una extensin propietaria
enlainterfazIDLpararealizarestaoptimizacin.
Si el servidor es capaz de procesar una peticin de consulta directamente, es
posiblesuponerqueelsiguientecdigopodraproducirunerror:
server.assign(Nombre,Luis);
if(server.read(Nombre)=!Luis){
ERROR(Incongruencia);
}
Si la operacin read se procesa inmediatamente, puede, de hecho, procesarse
antesquelaoperacinassign,conloqueelcdigoanteriorproduciraunerror.Sin
embargo,elclientequeejecutaelanteriorcdigo,lohacesecuencialmente,esdecir,
no ejecuta la operacin read hasta queassign hafinalizado,loqueevitalaanterior
incongruencia.
El segundo problema est asociado al modelo de transferencia de estado,
basado en mecanismos de archivo: obtener peridicamente el estado de la rplica
que se almacena junto con todos los mensajes recibidos desde que se obtuvo el
estado. El estado se puede obtener cada vez de forma completa o devolviendo
simplementeloscambiosefectuados.
La especificacin del servicio no detalla estos mecanismos, en particular no
precisa si todas las rplicas deben devolver peridicamente su estado o slo se
accede a una de las rplicas. Tampoco precisa cmo almacenar el estado. Una
solucin sera emplear un servicio de archivo tolerante a fallos, con loquebastara
con acceder a una de las rplicas. Sin embargo, esta solucin es complicada porla
dificultad asociada a ese servicio de archivo y la solucin bsica es acceder a cada
rplicayalmacenarsuestadodirectamenteenlamquinadondeseejecuta.
Este tipo de transferencia es perfectamente lgico en caso de replicacin
pasiva, donde slo una rplica conoce el estado de la aplicacin. Pero la obtencin
del estado implica el bloqueo de la rplica que lo transfiere, con lo que bloquear
todos los miembros del grupo de forma peridica slo puede redundar en un mal
rendimiento.
El tercer y ms importante problema est ligado con la imposibilidad del
servicio de soportar aplicaciones no deterministas. Pero, tal como ocurra con los
mecanismos de automatizacin del proceso dereplicacindesarrolladosalprincipio
de este captulo, el problema real se traduce en la imposibilidad de acceder a
componentes externos. Volviendo al ejemplo del generador de nmeros nicos
aleatorios, todas las rplicas deben ser capaces de generar el mismo nmero
aleatorio para mantener la consistencia del grupo. La solucin planteada fue el
empleo de un componente externo que generara ese nmero aleatorio, pero esta
solucines,sinoimposible,almenosmuydifcildeimplementarbajoCORBA.
Si todas las rplicas acceden al componente externo, ese componente recibe
mltiplesaccesos:enelcasodelgeneradordenmeros,nogenerarunosolo,como
se desea, sino tantos como rplicas haya. Consecuentemente, el servicio de
tolerancia a fallos debe interceptar no slo las llamadas a la rplica, sino las
llamadas efectuadas por sta, y coordinarlas con las llamadas de las otras rplicas
delgrupoparaqueserealiceefectivamenteunnicoaccesoalcomponentedado.
Esposiblerealizarestainterceptacinycoordinacindellamadas,auncuando
no est incluida en la especificacin CORBA e implica un peor rendimiento del
sistema. Adems el problema persiste porque no todos los accesos externos se
realizanacomponentesCORBAyelservicioserincapazdeinterceptarycoordinar
llamadasaunservidorftpohttp,porejemplo.Einclusoconrespectoacomponentes
CORBA,notodaslasllamadasdebensertampocointerceptadas.
Porejemplo,unaaplicacinpuedeemplearunasegundaaplicacinqueofrece
un servicio de traceado y que se ejecuta en la misma mquina que la primera.
Asumiendo que esta segunda aplicacin es CORBA, no tendra sentido que el
servicio de tolerancia a fallos interceptara las llamadas de todas las rplicas y
enviarasloinformacindetrazasdeunadelasrplicas:alrealizarestetraceadose
pretende saber qu ocurre con cada rplica. Pero si se fuera precisamente el
objetivo, la aplicacin no podra emplear ese servicio detraceadoenelcasoquesu
interfaz no fuera CORBA. Por ejemplo, con una interfaz basada en un protocolo
propietarioempleandodirectamentesockets.
Por lo tanto, el modelo CORBA soporta las mismas limitaciones que la
automatizacindelprocesodereplicacinquesepropusoenestecaptulo,dondese
producaunservidorreplicadoapartirdesuinterfazyunainstanciadelservidorno
replicado. Esa automatizacin dejaba sin cubrir un aspecto: las operaciones de
transferencia de estado, que son precisamente las mismas operaciones que deben
aadirse sobre un servidor no replicado al emplear el servicio de tolerancia a fallos
deCORBA.
Enelcasodelaautomatizacin,laslimitacionesseresolvieronfactorizandola
aplicacinencomponentes,peroestepasonoesposiblebajoCORBA,almenosbajo
laespecificacinactual.Comoconsecuencia,ysalvoqueseusereplicacinpasiva,el
dominio de aplicacin del servicio de tolerancia a fallos de CORBA se reduce a
servidoressencillos.
9.11.Conclusiones
La metodologa de construccin de aplicaciones tolerantes a fallos expuesta a
lolargodeestecaptulosebasaenelempleodecomponentesreplicados,intentando
reducir al mximo la lgica asociada a las comunicaciones en grupo entre rplicas
en una aplicacin tolerante a fallos, que se programa mediante el empleo de esos
componentes. Esta propuesta se fundamenta en dos ideas: el empleo de libreras
existentes de componentes ya probados y optimizados, y la posibilidad de
automatizarelprocesodereplicacindecomponentessencillos.
Un servicio tolerante a fallos contiene, en este caso, servidores sin un
conocimientomutuo,dondetodainteraccinserealizaatravsdeloscomponentes
replicados, que ofrecen la abstraccin de componentes compartidos. Esta
comparticin de recursos implica que los servidores los acceden simultneamente,
por lo que precisan de soluciones que impidan resultados inconsistentes por
actualizaciones concurrentes. Estas soluciones son los monitores replicados y las
transacciones.
Para facilitar la utilizacin de esos componentes, su empleo se simplifica
mediante el concepto de dominios, que permiten gestionarlos en su conjunto, y se
soporta su dinamismo: los componentes pueden crearse y eliminarse
dinmicamente, aumentando su semejanza a componentes normales y, por
consiguiente,sufacilidaddeuso.
Encomparacin,elserviciodetoleranciaafallosdeCORBAdefineunmodelo
muy simplificado, sin estos problemas de concurrencia. La diferencia estriba en la
granularidad en la replicacin: CORBA replica un servidor de forma monoltica
mientrasquelametodologaexpuestaenestecaptulopermitedefiniresareplicacin
aniveldecomponentes.Comoconsecuencia,elserviciodetoleranciaafallosCORBA
tiene muy poca aplicabilidad en replicacin activa, limitndose a servidores
sencillos.
El empleo de componentes replicados implica la posibilidad de disear
aplicaciones tolerantes a fallos a alto nivel, sin necesidad de emplear lasprimitivas
directamente soportadas en el modelo de sincrona virtual, basadas en vistas y
mensajes. Esta metodologa se basa totalmente en este modelo, que queda sin
embargoocultoparalaaplicacin.
Este captulo ha definido las facilidades necesarias para soportar esta
replicacin basada en componentes y ha especificado su implementacin en
trminos del soporte dado por un sistema de comunicaciones en grupo basado en
sincronavirtual.Dehecho,haceusoexclusivodelasprimitivasdecomunicaciones
empleando orden total causal, sin precisar el soporte de otros rdenes menos
restrictivos, lo que, sin embargo, implica la necesidad de que el grupo de
comunicaciones sobre el que se implemente tenga un buen rendimiento con las
comunicacionesconordentotal.
SenseiDomains 175
Captulo10-SENSEIDOMAINS
SenseiDomains es la implementacin del soporte de la metodologa
desarrollada en el anterior captulo, para el desarrollo de aplicaciones tolerantes a
fallosmedianteelempleodecomponentesreplicados.
La idea bsica es que todas las comunicaciones deben realizarse a travs de
SenseiDomains, el cual las delega a su vez al sistema de comunicaciones en grupo
subyacente. Los principales requisitos sobre dicho sistema de comunicaciones en
grupo son el empleo de un modelo de sincrona virtual y el soporte de
comunicaciones con orden total causal. Aunque el sistema de comunicaciones
subyacente pueda incluir otros rdenes menos restrictivos en los mensajes, en la
versin actual de SenseiDomains no se hanconsiderado.Laimplementacinactual
se realiza sobre SenseiGMS, pero su dependencia con este sistema de
comunicaciones se limita a su interfaz pblica. No hay ningn detalle de
implementacindeSenseiGMSsobreelquesebaseSenseiDomains,loqueasociado
a la generalidad de la interfaz de SenseiGMS, implica una fcil migracin a otros
sistemasdecomunicacionesdegrupo.
En lo referente a la transferencia de estado, SenseiDomains implementa la
interfaz de aplicacin mostrada en el captulo 7, con pequeas variaciones al no
tratarse de una implementacin del servicio de tolerancia a fallos de CORBA. Las
variaciones introducidas no restan, sin embargo, flexibilidad a la transferencia, que
presenta todas las caractersticas que se detallaron en aquel captulo. Esta
transferencia de estado se implementa totalmente en SenseiDomains, sin precisar
que el sistema de comunicaciones preste un soporte especfico de transferencia. El
SenseiDomains 176
captulo 4 se centr en los sistemas de comunicaciones en grupo existentes,
mostrando el soporte que presentan a la transferencia de estado, soporte que es,
cuandoexistente,inferioralqueprecisaSenseiDomains.
Adems de la limitacin al empleo de comunicaciones con orden total,
SenseiDomains no soporta el particionado del grupo. Esa falta de soporte no viene
dada por SenseiGMS, que tampoco lo soporta, sino porque, tanto la metodologa
expuesta en el captulo anterior, como el modelo de transferencia de estado
presentadoenloscaptulos5al7,soninsuficientesparaaplicacionesquepermiten
particionesdelgrupo.
La metodologa expuesta en el captulo anterior se centr en su aplicabilidad
bajo CORBA, pero es igualmente vlida para JavaRMI. Al igual que SenseiGMS,
SenseiDomainsdefineunainterfazcomnparaJavaRMIyCORBA,compartiendolos
algoritmos de implementacin. En este captulo explicamos exclusivamente la
interfazOMG/IDL;estainterfazesconsiderablementemsextensaquelanecesaria
para SenseiGMS, al igual que la implementacin resulta tambin mucho ms
compleja, por lo que incluir tambin la descripcin de las clases e interfaces Java
precisas para trabajar con JavaRMI supondra una extensin innecesaria, ya que
serarepetitivo.
LainterfazCORBAserepartefsicamenteenochopartesqueagrupandeforma
lgica las distintas definiciones; a cada uno de los ficheros le corresponde una
seccin en este captulo, para mantener esa agrupacin lgica. Todas las
definiciones se incluyen en el paquete Java sensei.middleware.domains, lo que
implica que estn definidas en el mdulo domains, incluido en el mdulo
middleware,definidoasuvezenelmdulosensei.
El nombre SenseiDomains viene dado por el elemento principal de la
metodologa, el dominio, que permite agrupar y gestionar los componentes
replicados: todas las caractersticas de la metodologa se definen en torno a este
concepto de dominio. La interfaz definida para el manejo de dominios es
DomainGroupHandler; sin embargo, esta interfaz depende [figura 10.1] en parte de
las dems entidades de SenseiDomains, por lo que no se define hasta las ltimas
secciones.
10.1.Excepciones
En DomainExceptions.idl se define una nica excepcin, correspondiente a
las operaciones efectuadas por el dominio bajo un estado incorrecto. Son posibles
otrasexcepciones,peroasociadasacaractersticasespecficasdeldominio,definidas
juntoaesascaractersticasenlasseccionessiguientes.
SenseiDomains 177
La mayora de las operaciones en el dominio son susceptibles de recibir una
excepcinMemberStateException,definidacomo:
enumMemberStateExceptionReason
{
MemberNotJoined,
MemberJoined,
MemberWithoutState,
MemberExcluded
};
exceptionMemberStateException
{
MemberStateExceptionReasonreason;
};
10.2.Transferenciadeestado
La definicin de la funcionalidad de transferencia de estado se incluye en
StateTransfer.idl.Elcaptulo7desarrolllainterfazdeaplicacindeunservicio
toleranteafallosCORBAconunatransferenciadeestadoflexible;SenseiDomainsno
es una implementacin de este servicio CORBA, por lo que la interfaz soportada es
ligeramentediferente,conelobjetivodeintegrarseconelmodelogenricodegrupos
Figura10.1.Jerarqua deherenciaen DomainGroupHandler
SenseiDomains 178
que emplea SenseiGMS. En cualquier caso, la flexibilidad es la misma, as que la
explicacin de las siguientes definiciones no es exhaustiva, para no duplicar la
informacinyadadaenelcaptulo7.
Esta definicin incluye tipos directamente definidos en la especificacin del
serviciodetoleranciaafallosdeCORBA,peroredefinealgunos,bienparaadaptarse
alainterfazdeSenseiGMS,bienparaaadiralgunafuncionalidad.Estostiposson:
abstractvaluetypeState{};
typedefGroupMemberIdLocation;
typedefsequence<Location>Locations;
interfaceCheckpointable:GroupMember
{
StategetState();
voidsetState(inStates);
};
typedefstringName;
typedefstringValue;
structProperty
{
Namenam;
Valueval;
};
State: es el estado a transferir entre rplicas, definido en CORBA como un tipo
any. SenseiDomains emplea un valuetype de tal forma que las aplicaciones
puedandefinirsupropiotipoynoprescindandelsoportedetipadodellenguaje.
Location: define la identidad de cada miembro del grupo, que viene dada en
CORBA por una cadena de caracteres (CosNaming::Name). SenseiGMS define
estas identidades con GroupMemberId, y empleamos este mismo tipo para
SenseiDomains.Delamismaforma,Locationsdefineunconjuntodemiembros.
Checkpointable: define la interfaz que todos los miembros de un grupo con
soporte de transferencia de estado deben implementar, correspondiente al
soporte ms simple en SenseiDomains. En CORBA, las operaciones emplean
nombres separados, como get_state en lugar de getState, y la interfaz no
extiende,obviamente,ladefinicinSenseiGMSdeGroupMember.
Property: las propiedades asociadas al grupo, o a un miembro dado, se definen
como pares {nombre, valor}. Bajo SenseiDomains,tantoelnombrecomoelvalor
de la propiedad se asocian a una cadena de caracteres para simplificar su
tratamiento,mientrasqueenCORBAlosvaloressontiposany.
SenseiDomains 179
La transferencia de estado planteada en los captulos anteriores soporta las
transferencias en varias etapas. Como se explic en la seccin 7.2.1, la aplicacin
debedefinirunaentidadquecontengalainformacinnecesariaparasincronizarlas
diferentes etapas. SenseiDomains slo emplea ese tipo para decidir cundo una
transferenciahafinalizado,predefiniendo,porlotanto,unapartedeesaentidad:
valuetypePhaseCoordination
{
publicbooleantransferFinished;
};
Laaplicacindefinesupropiacoordinacindefase,extendiendogeneralmente
este tipo previo. En cada etapa, debe asignar el valor correspondiente al campo
transferFinisheddelafase,dondeunvalortruemarcaelfinaldelatransferencia.
Un componente incluido en el dominio define el soporte de transferencia de
estado que precisa a partir de la interfaz que ese componente implementa. Las
interfacesdetransferenciadeestadoquepuedeimplementarson:
StateHandler:completosoportedetransferenciasenvariasetapas,admitiendola
interrupcindelastransferenciasporcambiosdevistas.
BasicStateHandler: soporte de transferencias en varias etapas, pero los cambios
devistassuponenlareiniciacincompletadelatransferencia.
ExtendedCheckpointable:soportebsico,similaraldefinidoenCORBA.
Checkpointable:soportebsico,talcomolodefineCORBA.
Sin implementar ninguna de las anteriores interfaces: sin soporte de
transferencia.
Estas interfaces se especifican a continuacin, sin incluir Checkpointable, que
ya se ha definidoanteriormente.Lanicaadicinconrespectoalainformacindel
captulo 7 es la interfaz ExtendedCheckpointable, que slo se diferencia de
Checkpointable en la operacin assumeState. Esta operacin permite que un
componentepuedadecidirculessuestadosinohayningunaotrarplicaqueselo
puedatransferir.
interfaceExtendedCheckpointable:Checkpointable
{
voidassumeState();
};
interfaceBasicStateHandler:GroupMember
{
voidassumeState();
voidstartTransfer(inLocationsjoiningMembers,inoutPhaseCoordinationphase);
StategetState(inoutPhaseCoordinationphase);
SenseiDomains 180
voidsetState(inStates,inPhaseCoordinationphase);
voidstopTransfer(inLocationsjoiningMembers,inbooleantransferFinished);
};
interfaceStateHandler:BasicStateHandler
{
voidsyncTransfer(inLocationcoordinator,inoutPhaseCoordinationphase);
voidinterruptTransfer(inoutPhaseCoordinationphase);
voidcontinueTransfer(inLocationsjoiningMembers,
inoutPhaseCoordinationcoordinator,
inPhaseCoordinationjoining);
};
Cada componente de un mismo dominio puede implementar una interfaz
diferente, no es preciso que todos los componentes requieran el mismo soporte de
transferencia de estado. Adems, esta interfaz soporta las transferencias
concurrentes: por ejemplo, cuando una transferencia comienza, la operacin
startTransferincluyeelconjuntodemiembrosquerecibirnelestado.Sinembargo,
la implementacin actual se limita a transferencias en serie: no es posible que un
miembrotransfieraelestadoavariosmiembrosconcurrentemente.
SenseiDomains permite la eleccin del coordinador de cada transferencia
mediantelassiguientesdefiniciones:
structCoordinatorInformation
{
LocationstatusMember;
LocationscurrentCoordinations;
};
typedefsequence<CoordinatorInformation>CoordinatorInformationList;
interfaceCoordinatorElector
{
LocationgetCoordinator(inLocationloc,inCoordinatorInformationListinfo);
};
Cada componente del dominio puede requerir un soporte de transferencia de
estado diferente pues, en caso contrario, se limitara la reusabilidad de los
componentesalpoderemplearconjuntamentesloaquellosquedefinieranelmismo
soportedetransferencia.Sinembargo,noesposiblequecadacomponentedecidael
coordinador para su transferencia: la aplicacin debe registrar un nico objeto que
implemente la interfaz CoordinatorElector, con la que elige un coordinador cada vez
queseprecisaunatransferencia.Pararealizarestaeleccin,laaplicacinrecibeuna
lista con todos los miembros con estado y, para cada uno de esos miembros, las
transferencias que estn realizando en ese momento dado, de tal forma que pueda
SenseiDomains 181
realizar balanza de carga (esta posibilidad no se incluye en la interfaz dada en el
captulo7).
No es necesario que la aplicacin implemente esta interfaz: encasocontrario,
laeleccinlarealizaeldominiomismo,comoseexplicamsadelante.
El ltimo tipo definido especifica el comportamiento de la aplicacin ante
cambiosdeestados:
enumBehaviourOnViewChanges
{
MembersOnTransferExcludedFromGroup,
StatelessMembersDoNotBelongToGroup,
StatelessMembersBelongToGroup
};
Durantelatransferencia,SenseiDomainsbloquealosmensajesalosmiembros
que la realizan, salvo que esos mensajes se definan como de no bloqueo. Ante un
cambio de vista, BehaviourOnViewChanges define las acciones a tomar con esos
mensajes:
MembersOnTransferExcludedFromGroup: los miembros en la transferencia se
consideran excluidos del grupo, por lo que no se ven afectados por los cambios
devista.Losmensajesquedanencoladosysloseenvanalaaplicacincuando
la transferencia ha concluido. Permite implementar las transferencias ms
sencillas, pero no respeta completamente el modelo de sincrona virtual.Puesto
que la transferencia no se interrumpe, no resulta lgico implementar la
complicadainterfazStateHandlercuandosedefineestecomportamiento.
StatelessMembersDoNotBelongToGroup: considera que los miembros sin estado
nopertenecenalgrupo.Anteuncambiodevista,latransferenciaseinterrumpe
y el miembro que la coordina recibe los mensajes que se hubieran bloqueado,
que debe procesar antes de instalar la nueva vista. El miembro sin estado, sin
embargo,norecibeesosmensajes,quesondescartados.
StatelessMembersBelongToGroup: todos los miembros se consideran incluidosen
el grupo, siendo sta la nica opcin que permite una solucin que se adhiere
completamente al modelo de sincrona virtual. Se comporta como en el anterior
caso, pero el nuevo miembro recibe tambin los mensajes bloqueados antes de
procesarlanuevavista.
PuestoqueSenseiDomainssoportatransaccionesque,comomostrelcaptulo
anterior no se adhieren estrictamente al modelo de sincrona virtual, el
comportamiento por defecto ante vistas es el que soporta una transferencia ms
simple:MembersOnTransferExcludedFromGroup.
Los protocolos que soportan la interfaz de transferencia de estado fueron
definidoscomopushopull,segnelmiembrosinestadorecibieraautomticamente
desde otro miembro el estado o tuviera que solicitarlo explcitamente. La interfaz
SenseiDomains 182
pblica en ambos casos es la misma, luego la eleccin del protocolo afecta
nicamente al rendimiento. Se demostr que, excepto en casos concretos y con
soporte multipunto del medio empleado, el protocolo push ofrece mejores
rendimientos, por lo que la versin actual de SenseiDomains implementa
nicamenteesteprotocolo.
10.3.Propiedades
Alestudiarlatransferenciadeestadoserealizunadistincinentreelestado
de un miembro y sus propiedades, y se defini la interfaz necesaria para soportar
stas. Esa interfaz estaba muy ligada al servicio de tolerancia a fallos CORBA,
empleando entidades bsicas de ese servicio, como el PropertyManager o las
GenericFactory (seccin 7.4). La solucin aportada pretenda integrarse en la
especificacin hecha del servicio CORBA, introduciendo los mnimos cambios
posibles para obtener la flexibilidad deseada. Esta integracin no es precisa en
SenseiDomains, e introducir las entidades necesarias supondra una complejidad
adicionalsinaportarningunaventaja.
Por estarazn,Properties.idldefinelasinterfacesnecesariasparasoportar
la funcionalidad de propiedades descrita en el captulo 7, pero sin emplear las
entidadesCORBA.Estecambiopermite,ademsdeincrementarlafuncionalidad,un
manejodelaspropiedadesmsflexiblequeenladescripcininicial.Posteriormente
a esta primera descripcin hemos introducido el concepto de dominio, agrupando
componentes que podran definir sus propias propiedades. Sin embargo, las
propiedades deben emplearse a nivel de dominio, no a nivel de componente, y
asocindose, por tanto, al servidor replicado y no a los componentes que lo
constituyen.
La estructura MemberProperties asocia a un miembro dado un conjunto de
propiedades:
structMemberProperties
{
GroupMemberIdmember;
Propertiesprops;
};
Deformagenrica,cuandounaentidaddebeusarseenlistassedefineuntipo
especfico,identificadoparaMemberPropertiescomoMemberPropertiesList.
El captulo 6 desarroll los protocolos de bajo nivel que soportan la
transferenciadeestadoydepropiedadesentremiembros.Elempleodepropiedades
afecta a esos protocolos, que deben emplear ms mensajes y con ms informacin,
inclusosiungrupoespecficonohaceusodeesaspropiedades.Paraoptimizareste
SenseiDomains 183
casoeimpedirqueelrendimientodeungruposeresientaporunafacilidadqueno
emplea,esposibleespecificarqueeldominionoutilizapropiedades,encuyocasono
se permite emplear las operaciones de manejo de esas propiedades. Si se emplean,
seobtieneunerror,asociadoalasiguienteexcepcin:
exceptionPropertiesDisabledException
{
};
Todoslosmiembrosdeldominiodebenutilizarlamismapolticadeempleode
propiedades: o todos los miembros soportan propiedades o ninguno lo hace. Si se
emplean propiedades, un miembro del dominio puede recibir notificaciones de
cambios en las propiedades de otros miembros. Esta notificacin no incluye los
cambios,slosumbito:
interfacePropertiesListener
{
voidpropertiesUpdated(inLocationloc);
};
Las propiedades se modifican y se consultan empleando la interfaz
PropertiesHandler:
interfacePropertiesHandler
{
voidenableProperties()raises(MemberStateException);
booleanarePropertiesEnabled();
voidsetPropertiesListener(inPropertiesListenerlistener)
raises(PropertiesDisabledException);
MemberPropertiesListgetAllProperties()
raises(MemberStateException,PropertiesDisabledException);
MemberPropertiesListgetPropertyForAllMembers(inNamenam)
PropertiesgetMemberProperties(inLocationloc)
ValuegetMemberProperty(inLocationloc,inNamen)
PropertiesgetProperties()raises(PropertiesDisabledException);
ValuegetProperty(inNamen)raises(PropertiesDisabledException);
voidsetProperties(inPropertiesprops)
voidaddProperties(inPropertiesprops)
voidremoveProperties(inPropertiesprops)
};
SenseiDomains 184
Estas operaciones se dividen en cuatro tipos. El primer tipo agrupa las
operacionesqueafectanalmanejoglobaldepropiedades:
enableProperties: por defecto, el dominio no soporta propiedades, que deben
habilitarse explcitamente, siendo imposible deshabilitarlas posteriormente.
Adems, esta operacin debe efectuarse antes de incluir al miembro en un
grupo,momentoenqueseinicianlosprotocolosentremiembros,oserecibeuna
excepcinMemberStateException.
arePropertiesEnabled: mtodo de consulta, permite conocer si las propiedades
hansidohabilitadas.
setPropertiesListener: registra la instancia PropertiesListener que recibe las
notificaciones de cambios de propiedades. Esta instancia puede modificarse en
cualquier momento, salvo que no se hayan habilitado las propiedades. El
argumentopuedesernuloparadejarderecibirnotificaciones.
Elrestodeoperacionesslopuedenserinvocadassilaspropiedadeshansido
habilitadas. El segundo grupo de operaciones permite modificar las propiedades de
unmiembrodelgrupo.Debenotarsequelaspropiedadesdeunmiembroespecfico
slopuedensermodificadasporesemiembroysiemprequenohayasidoexpulsado
delgrupo,encuyocasoselanzaraunaexcepcinMemberStateException:
setProperties: fija el conjunto de propiedades, eliminando toda propiedad
previamentedefinida.
addProperties: aade las propiedades dadas, sobrescribiendo las ya existentes
conelmismonombre.
removeProperties:eliminalaspropiedadesespecificadas.Noseconsideraunerror
eliminarunapropiedadnodefinida.
Las operaciones que permiten observar las propiedades del miembro propio
conformaneltercergrupo:
getProperties: devuelve el conjunto de propiedades definidas para el propio
miembro.
getProperty: devuelve una propiedad especfica del propio miembro; si no se ha
definidotalpropiedad,sedevuelveunareferencianula.
El ltimo grupo incluye a las operaciones que devuelven las propiedades de
otros miembros del grupo. Como slo es posible obtener informacin de otros
miembros si se ha completado la transferencia de estado, es un error invocar a las
siguientesoperacionessobremiembrossinestado:
getAllProperties:devuelvelaspropiedadesdetodoslosmiembros.
getPropertyForAllMembers: devuelve elvalordeunapropiedadespecficaencada
unodelosmiembrosdelgrupo.
getMemberProperties:devuelvelaspropiedadesdeunmiembroespecfico.
SenseiDomains 185
getMemberProperty: devuelve una propiedad especfica de un miembro
determinado.
Gran parte de la funcionalidad proporcionada puede parecer superflua, pues
los tres ltimos grupos de operaciones podran sintetizarse en dos operaciones:
setProperties, getProperties. Como contrapartida, se obtiene una mayor facilidad de
uso y un mejor rendimiento en casos especficos, como por ejemplo, al emplear
getPropertyForAllMembers.
La interfaz DomainGroupHandler implementa la interfaz PropertiesHandler, es
decir,todoelmanejodepropiedadesserealizaatravsdeladefinicindedominio.
10.4.Componentes
En SubgroupsHandler.idl se define lagestindecomponentespropuestaen
el captulo anterior, que emplea indistintamente los trminos subgrupo y
componente. Esta propuesta distingua entre dos tipos decomponentes,estticosy
dinmicos,segnfuerasuciclodevida.Ambostipossonidentificadoseneldominio
empleando una identidad, pero los primeros deben suministrar esa identidad
mientrasqueeseldominioelqueasignalaidentidaddelossegundos.
Las identidades de los componentes se definen como enteros en
SenseiDomains, que incluye, adems, una limitacin adicional, al diferenciar los
rangos de identidades que pueden emplearse para componentes estticos y
dinmicos. Se define, tambin, una identidad de componente universal, aplicable a
todoslossubgruposdeldominio:
typedeflongSubgroupId;
typedefsequence<SubgroupId>SubgroupIdsList;
constlongEVERY_SUBGROUP=0;
constlongMAX_STATIC_SUBGROUP_ID=65535;
Allimitarlosrangosdeidentidades,intentarregistraruncomponenteconuna
identidad invlida o ya usada, provoca un error, para lo que define una excepcin
especfica SubgroupsHandlerException, usada tambin al emplear componentes
dinmicoserrneamente:
enumSubgroupsHandlerExceptionReason
{
SubgroupIdAlreadyInUse,
InvalidStaticSubgroupId,
InvalidDynamicSubgroupId,
DynamicBehaviourNotRegistered
};
exceptionSubgroupsHandlerException
{
SenseiDomains 186
SubgroupsHandlerExceptionReasonreason;
};
Sieldominioempleacomponentesdinmicos,unmiembrolocreatrashaberse
incorporado al grupo y losdemsmiembrosdebencrearesemismocomponenteen
su espacio de memoria. Para que estos miembros conozcan el componente que
debencrear,elprimerodebeenviarciertainformacinquelepermitaalaaplicacin
seleccionareltipodecomponenteadecuado.Estainformacinsedefineapartirdel
tipoDynamicSubgroupInfo,definidosimplementecomo:
valuetypeDynamicSubgroupInfo
{
};
La aplicacin debe definir un tipo concreto, a partir del anterior, que incluya
esa informacin, que es totalmente opaca para SenseiDomains. Como facilidad
adicional, se incluye un tipo concreto para el caso en que la informacin pueda
darsemedianteunacadenadecaracteres:
valuetypeDynamicSubgroupInfoAsString:DynamicSubgroupInfo
{
publicstringinfo;
};
El empleo de componentes dinmicos implica que la aplicacin debe
suministrar funcionalidad adicional que permita la creacin de componentes en
demanda, as como su eliminacin. Esta funcionalidad se proporciona al crear y
registrarunobjetoqueimplementelainterfazDynamicSubgroupsUser:
interfaceDynamicSubgroupsUser
{
GroupMemberacceptSubgroup(inSubgroupIdid,
GroupMembersubgroupCreated(inGroupMemberIdcreator,
inSubgroupIdid,
voidsubgroupRemoved(inGroupMemberIdremover,
inSubgroupIdid,
};
subgroupRemoved: comunica a la aplicacin que un miembro del grupo ha
eliminadouncomponentedado.Larazndeesaeliminacin,siesnecesaria,se
incluyemedianteunparmetrodetipoDynamicSubgroupInfo.
acceptSubgroupysubgroupCreated:ambasoperacionesseempleanparasolicitar
a la aplicacin que cree un componente dado. La primera operacin se invoca
SenseiDomains 187
cuando el miembro se une al grupo y recibe informacin de los componentes
dinmicos ya existentes, mientras que la segunda se invoca cuandoelmiembro
yapertenecealgrupo.Ladiferenciaesquesloenelprimercasoelcomponente
recibeunatransferenciadeestado.
LadistincinentreacceptSubgroupysubgroupCreatedsecomprendemejorcon
un ejemplo. Un componente que implementa un rbol binario replicado se crea
vaco, sin elementos, por lo quenoesnecesarioquesetransfierainformacinalas
dems rplicas cuando se crea dinmicamente. En este caso, esas rplicas reciben
una llamada subgroupCreated con la que crean un componente vaco. Si en algn
momento se incluye un nuevo miembro en el grupo, recibe la solicitud
acceptSubgroupparacrearesecomponentepero,enestecaso,suestadovaconoes
consistenteconelgrupoydeberecibirelestadodesdeotrarplica.
Esta aproximacin es obviamente una generalizacin, pues hay componentes
que pueden necesitar para su inicializacin de una informacin dada. En ese caso,
estainformacinpuedeincluirseeneltipoDynamicSubgroupInfo,siempreycuando
su tamao no sea considerado grande pues, en caso contrario, el componente
debera definir sus propios mtodos de inicializacin de estado. Por ejemplo, en un
sistema replicado de ficheros, el componente fichero debera necesitar para su
construccinelnombreasignado.Sisepretendecrearlodirectamenteconcontenido,
elcontenidodeunficheropodrafcilmenteexcederlosmegabytes,encuyocasoes
difcilmente defendible la inclusin de esa informacin en un objeto de tipo
DynamicSubgroupInfoysureplicacinenunnicopaso:elcomponentedebedefinir
suspropiasoperacionesparasoportarestainicializacin.
LagestindecomponentesserealizaatravsdelainterfazSubgroupsHandler:
interfaceSubgroupsHandler
{
voidsetDynamicSubgroupsUser(inDynamicSubgroupsUseruser)
raises(MemberStateException);
voidregisterSubgroup(inSubgroupIduniqueSubgroupId,inGroupMembersubgroup)
raises(MemberStateException,SubgroupsHandlerException);
voidcastSubgroupCreation(inDynamicSubgroupInfoinfo)
SubgroupIdcreateSubgroup(inDynamicSubgroupInfoinfo,inGroupMembersubgroup)
booleanremoveSubgroup(inSubgroupIdid,inDynamicSubgroupInfoinfo)
SubgroupIdsListgetSubgroups();
GroupMembergetSubgroup(inSubgroupIdid);
SubgroupIdgetSubgroupId(inGroupMembersubgroup);
};
setDynamicSubgroupsUser: registra la instancia que recibe las notificaciones de
creacin y eliminacin de componentes dinmicos. Si el miembro no define
SenseiDomains 188
ninguna instancia, no soportar componentes dinmicos. Tal como ocurre con
las propiedades, todos o ninguno de los miembros del grupo deben soportar
componentesdinmicos.
registerSubgroup: registra un componente esttico en el dominio, especificando
suidentidad.Loscomponentesestticosdebenregistrarseantesdeincorporarel
dominioasugrupo.
castSubgroupCreation: comunica al grupo que se va a crear un nuevo
componente dinmico. En esta operacin no se incluye el componente que se
crea, por lo que deber crearlo posteriormente en demanda, como las dems
rplicas,alrecibirlanotificacinsubgroupCreated.
createSubgroup:creacindeuncomponentedinmico,comoenelanteriorcaso.
Sinembargo,eldominioobtieneahoraesecomponentey,portanto,laaplicacin
no recibir posteriormente la notificacin subgroupCreated. Esta operacin se
bloquea hasta que cada rplica del grupo recibe la notificacin de creacin del
nuevocomponente.
removeSubgroup: elimina el componente dado. Slo es posible eliminar los
componentesdinmicos.
getSubgroups:permiteobtenerlalistadecomponentesdefinidos,tantoestticos
comodinmicos.
getSubgroup:devuelveelcomponenteasignadoalaidentidadespecificada,ouna
referencianula,sinoexistetalcomponente.
getSubgroupId:devuelvelaidentidaddelcomponentedado.Sielcomponenteno
pertenecealdominio,elvalordevueltoesEVERY_SUBGROUP.
Los componentes no deben emplear ninguna nueva interfaz, implementan la
interfazGroupMemberdefinidaenSenseiGMS,pueslaabstraccinquedaeldominio
es la de agrupar componentes que de otra forma deberan definir su propio grupo
independiente de rplicas, implementando igualmente la interfaz GroupMember. La
interfaz DomainGroupHandler implementa la interfaz SubgroupsHandler y gestiona,
porlotanto,loscomponentesdeldominio.
10.5.Mensajes
SenseiGMSeselsistemadecomunicacionesempleadoparaenviarfiablemente
mensajesentrerplicas.Sinembargo,losmensajessedefinenaniveldeaplicaciny
sucontenidoestotalmenteopacoparaSenseiGMS.
SenseiDomains s necesita enviar informacin adicional en cada mensaje
como, por ejemplo, la identidad del componente al que afecta. Por esta razn, se
define en DomainMessage.idl un mensaje con toda la informacin necesaria; este
SenseiDomains 189
mensaje debe ser extendido por la aplicacin para que incluya su informacin
especfica,talcomoocurrabajoSenseiGMS.Ladefinicinbasees:
typedeflongMessageId;
valuetypeDomainMessage:Message
{
publicSubgroupIdsubgroup;
publicbooleanunqueuedOnST;
publicbooleanunTransactionable;
publicbooleanwaitReception;
publicMessageIdid;
};
DomainMessageextiendeladefinicindeMessage,necesarioparasuenvopor
SenseiGMS. Define cinco atributos, de los que slo tres son asignados por la
aplicacin.
subgroup: identidad del componente al que afecta. Un valor EVERY_SUBGROUP
seempleaparaenviarelmensajeatodosloscomponentes.
unqueuedOnST:sisedefineesteatributocomotrue,elmensajenoesbloqueado
durante las transferencias de estado. Un ejemplo de este tipo de mensajes son
los definidosporelpropiodominioparaimplementarlatransferenciadeestado.
Pordefectoseinicializaafalse,todoslosmensajessonbloqueados.
unTransactionable:aldefiniresteatributocomotrue,elmensajenoesbloqueado
durantetransacciones.Elatributopreviobloquealosmensajesenrecepcin,en
tantoesteatributolosbloqueaenenvo.Pordefectoseinicializatambinafalse.
waitReceptionyid:usadosinternamenteporeldominio.
El captulo anterior mostr la restriccin de que todo mensaje no
transaccionable tampoco puede ser bloqueado durante transferencias. Por lo tanto,
el valor del atributo unTransactionable es irrelevante si unqueuedOnST contiene el
valorpordefecto.
10.6.Controldeconcurrencia
Laconcurrenciasobrecomponentesreplicadossecontrolamediantemonitores
ytransacciones,ambosdefinidosenMonitor.idl.
Lainterfazquedebesoportarunmonitorreplicadosedetallenlaseccin9.6.
Su explicacin incluy la posibilidad de un empleo incorrecto de estos monitores
SenseiDomains 190
como, por ejemplo, liberarlos cuando no han sido previamente adquiridos, lo que
suponelanecesidaddeunaexcepcinespecfica,MonitorException:
exceptionMonitorException
{
};
El empleo de un monitor replicado puede provocar errores adicionales
relacionados con el estado del miembro en el grupo, que se identifican con la
excepcinMemberStateException,yadefinida.LainterfazMonitorsedefinecomo:
interfaceMonitor
{
voidlock()raises(MemberStateException);
voidunlock()raises(MonitorException,MemberStateException);
};
Donde la operacin lock adquiere el monitor y unlock lo libera. La semntica
concreta se explica detalladamente en el captulo anterior; especficamente, los
monitores deben ser reentrantes, es decir, un monitor puede ser readquirido
repetidasveces.
LainterfazMonitornodefine,sinembargo,uncomponenteespecficomonitor
replicado, sino las operaciones que todo monitor debe soportar. La distincin es
importante;enJava,porejemplo,todoslosobjetostienenasociadounmonitor,por
lo que puede considerarse que extienden una interfaz Monitor (con la semntica
propia de monitores del lenguaje). De la misma forma, es posible definir un
componente replicado cualquiera que incluya su propio acceso a recursos e
implementesuinterfazentrminosdeestainterfazMonitor.Enelcasodeunalista,
porejemplo,seraposibledefinirlacomo:
interfaceList:Monitor
{
...
};
Este componente permitira un acceso sincronizado sin necesidad de otro
componenteadicionalqueimplementaraelmonitorreplicado.
SenseiDomains define e implementa, ademsdeestainterfaz,uncomponente
replicadoespecficoconestafuncionalidad,denominadoGroupMonitor:
interfaceGroupMonitor:Monitor,ExtendedCheckpointable
{
};
EstecomponentedefinesimplementelamismainterfazMonitoryelsoportede
transferencia de estado que precisa: una aplicacin puede crear un componente
SenseiDomains 191
GroupMonitor para realizar el sincronizado sobre accesos concurrentes. Es el nico
componente replicado definido en implementado en SenseiDomains, por su
necesidadparaelempleodetransacciones.
Una aplicacin puede realizar sus propias implementaciones de monitores,
siempre y cuando extiendan la interfaz Monitor. Debe tenerse en cuenta que el
mensaje asociado a la adquisicin del monitor es no transaccionable, luego no se
bloquea durante las transacciones. Por esta razn, es necesario considerar la
posibilidaddereconstruirelestadodelmonitorapartirdemensajesdeadquisicin
y liberacin que pudieran llegar en orden incorrecto. La implementacin en
SenseiDomainssoportadirectamenteesteescenario.
Lastransaccionessonmecanismosnecesariosparaelempleodecomponentes,
puespermitenconservarlaconsistenciaenelgrupoauncuandolarplicacaigasin
haber completado una actualizacin que afecte a mltiples componentes. Sin
embargo, puesto que su uso viola el modelo de sincrona virtual, una aplicacin
estrictamente adherida al modelo debe poder evitarlas. En este caso, el empleo de
transaccionesprovocaunaexcepcin:
exceptionTransactionException
{
};
Como detalle de implementacin, en SenseiDomains no es posible especificar
explcitamente cundo las transacciones son permisibles o no. Este permiso se
determina indirectamente a partir del valor dado a BehaviourOnViewChanges, el
comportamiento ante cambios de vista. Este valor se emplea para definir el
tratamiento de mensajes durante transferencias ante cambios de vistas, definiendo
tresmodosdelosqueslounoestotalmentecompatibleconelmodelodesincrona
virtual.Estacompatibilidadimplicaunamayorcomplejidadenlaimplementacinde
los algoritmos de transferencia, por lo que su empleo implica una adherencia al
modelo y la imposibilidad, por tanto, de usar transacciones. Si un dominio no se
defineconvalorMembersOnTransferExcludedFromGroup,queeselvalorpordefecto,
seconsideraquenosoportatransacciones.
LastransaccionessemanejanmediantelainterfazTransactionHandler:
interfaceTransactionsHandler
{
voidstartTransaction(inMonitorlocker)
raises(MonitorException,TransactionException,MemberStateException);
voidendTransaction()
};
La transaccin se realiza en torno al monitor especificado al iniciarla, no
siendo necesario especificarlo de nuevo para completarla, aunque se aniden las
SenseiDomains 192
transacciones. Los cambios realizados en los componentes del dominio durante la
transaccinnosereflejanenlasdemsrplicassilarplicaquelosrealizasecaeo
es expulsada del grupo sin haber completado todas sus transacciones en curso. La
implementacindeSenseiDomainsimplicaquerealizarlamodificacindedosoms
componentesenunatransaccinofrecemejoresresultadosquesinoseempleaesa
transaccin.
La interfaz TransactionHandler es extendida por DomainGroupHandler, por lo
que las transacciones se manejan a travs del concepto de dominio, como se
propusoenelcaptuloanterior.
10.7.Dominios
Como se adelant en la introduccin, el concepto de dominio lo define la
interfazDomainGroupHandler,especificadaenDomainGroupHandler.idl.
Un dominio es un grupo que aglutinalgicamenteunaseriedecomponentes,
que de otra forma hubieran constituido otros tantos grupos independientes,
permitiendoassugestinconjunta.Alimplementarunafuncionalidadadicional,la
interaccin con el dominio es ms complicada que la que haba con el grupo en
SenseiGMS.Laexpulsindeunmiembrodesugrupodecomunicacionessedebe,en
todos los casos, a problemas,realesovirtuales,ensusenlacesdecomunicaciones.
La expulsin de un miembro de un grupo gestionado mediante un dominio puede,
sin embargo, deberse a otras razones, generalmente violaciones del modelo de
dominios.Porestemotivosehadefinidountipoqueenumeraestasrazones:
enumDomainExpulsionReason
{
GMSLeaveEvent,
WrongPropertyAllowance
WrongStaticSubgroupsComposition,
WrongCoordinatorElectionPolicy,
WrongBehaviourMode,
WrongDynamicPolicy,
WrongSubgroupsTypes,
SubgroupError
};
GMSLeaveEvent: la expulsin no la ha originado el dominio, sino el mismo
substratodecomunicaciones,seaporpeticindelaaplicacinoporunerrorde
lascomunicacionesenelgrupo.
WrongPropertyAllowance: el miembro que se aade al grupo no presenta los
mismos permisos de propiedades que los miembros ya existentes. Todos los
miembrosdelgrupodebendefinirlamismapolticadeempleodepropiedades.
SenseiDomains 193
WrongStaticSubgroupsComposition: el miembro que se aade al grupo no ha
definidolosmismoscomponenteseidentidadesquelosmiembrosyaexistentes.
WrongCoordinatorElectionPolicy: es tambin obligatorio que o todosoningunode
los miembros del grupo sean capaces de elegir al coordinador de una
transferencia.
WrongBehaviourMode:elmiembroqueseincluyeenelgrupohadefinidounvalor
diferenteparaBehaviourOnViewChangesquelosmiembrosyaexistentes.
WrongDynamicPolicy: no se ha cumplido el requisito asociado a componentes
dinmicos, por el que todos los miembros del grupo deben emplear la misma
aproximacinencuantoapermitirlosono.
WrongSubgroupsTypes: cada componente se instancia en cada miembro del
dominioy,paraquelatransferenciadeestadoseaposible,esnecesarioqueesos
componentes implementen las mismas interfacesdesoportedetransferenciaen
cada una de las rplicas. En caso contrario, se obtiene este motivo en la
expulsin.
SubgroupError: el dominio ha recibido una excepcin al acceder a uno de los
componentes,loquesuponesuautoexclusindelgrupo.
El dominio genera tambin eventos asociados al grupo decomponentesensu
conjunto, que la aplicacin puede recibir si crea y registra una instancia de la
interfazDomainGroupUser:
interfaceDomainGroupUser
{
voiddomainAccepted(inGroupMemberIdid);
voiddomainExpulsed(inDomainExpulsionReasonreason);
voidstateObtained(inbooleanassumed);
voidoffendingSubgroup(inSubgroupIdsubgroup,instringreason);
};
domainAccepted:eventodeaceptacinenelgrupo,incluyelaidentidaddegrupo
asignada. Por otra parte, todos los componentes del dominio reciben el evento
memberAccepted definido en GroupMember, que incluye igualmente la identidad
degrupo,siendoobviamentelamismaparatodosloscomponentesdeldominio.
domainExcluded: expulsin del grupo, incluye la razn aducida por el dominio
para tal expulsin. Los componentes reciben el evento expulsedFromGroup,
aunquenoelmotivodelaexpulsin.
stateObtained: obtencin de estado, evento obtenido una vez que el dominio se
consideraconestado,bienporquelohayarecibidoobienporqueseleconsidere
el miembro primario de un grupo sin miembros con estado. En este segundo
caso,seconsideraqueeldominioasumesuestado.
SenseiDomains 194
offendingSubgroup: evento producido por un problema en un componente del
dominio.Aesteeventolesigueeventualmenteeldeexpulsindelgrupo.
Finalmente,lainterfazDomainGroupHandlerdedefinecomo:
interfaceDomainGroupHandler:GroupHandler,GroupMember,
PropertiesHandler,SubgroupsHandler,TransactionsHandler
{
voidsetBehaviourMode(inBehaviourOnViewChangesmode)
voidsetCoordinatorElector(inCoordinatorElectorelector)
voidsetDomainGroupUser(inDomainGroupUseruser)
GroupMemberIdListgetStatefulMembers()raises(MemberStateException);
booleansyncCastDomainMessage(inDomainMessagemessage,
inbooleannormalProcessing)
voidsyncCastDomainMessageProcessed()
raises(MemberStateException,SyncCastDomainMessageProcessedException);
};
Lafigura10.2muestralasprincipalesdependenciasdeestadefinicin:
DomainGroupHandler se comporta como GroupHandler, que es la interfaz
empleada en SenseiGMS para interaccionar con el grupo. Al emplear dominios,
Figura10.2.Principalesdependencias deDomainGroupHandler
SenseiDomains 195
toda la interaccin con el grupo se realiza a partirdeDomainGroupHandler,que
implementa, por lo tanto, la funcionalidad de GroupHandler como, por ejemplo,
la exclusin del grupo o el envo de mensajes. La interfaz GroupMember, que
implementan los componentes, define el evento memberAccepted, por el que los
componentes reciben la instancia GroupHandler cuando son aceptados en el
grupo;alemplearlosenundominio,lainstanciaquerecibeneneseeventoesla
deldominiomismo.
Asuvez,DomainGroupHandlereselmiembrodeungrupoderplicas,dondelos
otros miembros son instancias equivalentes del mismo dominio. Por esta razn
debeimplementarlainterfazGroupMember,segnladefineSenseiGMS.
DomainGroupHandler es la entidad que gestiona las propiedades del dominio,
implementandolainterfazPropertiesHandler.Admiteelregistrodeunainstancia
PropertiesListener que recibe las notificaciones de cambios de propiedades en el
grupo.
DomainGroupHandler es el gestor de componentes, que implementa la interfaz
SubgroupsHandler. Es capaz de soportar componentes dinmicos si se registra
unainstanciaDynamicSubgroupsUsereneldominio.
Por ltimo, DomainGroupHandler extiendelainterfazTransactionsHandler,porlo
quesoportaelusodetransaccionessobreloscomponentesquegestiona.
Adems del comportamiento definido por herencia, soporta la siguiente
funcionalidad:
setBehaviourMode; permite fijar el comportamiento de la transferenciadeestado
ante cambios de vistas. El comportamiento por defecto es el correspondiente a
MembersOnTransferExcludedFromGroup; en caso de cambiarlo, el nuevo valor
debefijarseantesdeincluiraldominioenelgrupo.
setDomainGroupUser: registra la instancia DomainGroupUser que recibe los
eventosdeldominio.
getStatefulMembers: devuelvelalistademiembrosdelgrupoconestado.Lalista
detodoslosmiembros,conosinestado,esunainformacinqueyaserecibea
travsdelasvistas.
setCoordinatorElector: registra la instancia CoordinatorElector empleada para la
eleccin del coordinador. Si no se define ninguna instancia, el algoritmo por
defecto en SenseiDomains distribuye las transferencias entre los miembros con
estado,realizandounabalanzadecargaefectiva.
Una caracterstica especial de SenseiDomains es que soporta una balanza de
carga con pesos. Es posible asignar a cada miembro del dominio la propiedad
weight, cuyo valor determina su peso en esta balanza de carga. Por ejemplo, un
miembro en el que esta propiedad tiene el valor 2.0 soporta el doble nmero de
transferencias que otro con valor 1.0, mientras que uno con valor 0.0 slo
intervendr en la transferencia si no hay otros miembros con estado con un valor
SenseiDomains 196
superior.Deestaforma,esposiblefijarelpapeldecadamiembroenlatransferencia
sinnecesidaddecrearuncomponenteCoordinatorElector.Porejemplo,ungrupoque
destina un miembro especfico para las transferencias, de tal forma que los dems
miembros no pierdan disponibilidad, puede asignaraesemiembrounpesogrande,
porejemplo1000,dejandoelvalorpordefectoenlosotrosmiembros.
Quedan dos operaciones de la interfaz DomainGroupHandler por explicar,
relacionadas con el patrn de sincronizacin de mensajes que se desarroll en la
primeraseccindelcaptuloanterior.Estepatrnpermitesincronizarlasolicitudde
un servicio en una rplica con el proceso asncrono de obtener una respuesta tras
comunicarseconlasotrasrplicas.Adems,soportadosvariantes:laelaboracinde
larespuestasehaceenelmismothreadquerealizalacomunicacinconelgrupo,o
en el thread que recibe las comunicaciones del grupo. Si la solicitud de servicio
requieredevolveralgnvaloralcliente,debeemplearse,preferiblemente,laprimera
variante; si no devuelve ningn valor, ambas variantes son adecuadas. Las
operacionesson:
syncCastDomainMessage: enva el mensaje al dominio y se bloquea este thread
hasta que ese mismo mensaje se reciba. El parmetro normalProcessing indica
dndeseprocesaesemensaje;sisuvalorestrue,seprocesaenlarecepcindel
mensaje, y el bloqueo slo termina cuando se ha completado su proceso. Si es
false, el bloqueo finaliza al recibir el mensaje, lo que permite al proceso que
inicilallamadasyncCastDomainMessagedespertarseyprocesarelmensajeque
envi. En este caso, el componente no observa la recepcin del mensaje, y es
necesario que, tras procesar el servicio, invoque la operacin
syncCastDomainMessageProcessed,oeldominioenteroquedabloqueado.
syncCastDomainMessageProcessed: completa la sincronizacin de un servicio
queseprocesaenenvo.
Empleamosunejemploparaclarificarsuuso,basadoenelqueseutilizenel
captulo anterior para exponer este patrn de sincronizacin. La operacin
getNumber devuelve un nmero secuencial, incrementado cada vez que se invoca
sobrecualquierrplicadelgrupo,detalformaquenuncasedevuelvandosnmeros
iguales. La operacin getNumber se traduce en un mensaje GetNumberMessage que
noincluyeningunainformacinadicional.
Elsiguientelistadomuestraelcdigoasociadoalaprimeraalternativa:
publicclassNumberGenerator:...
{
DomainGroupHandlerdomain;
intlastGeneratedNumber;
...
publicintgetNumber()
SenseiDomains 197
{
domain.syncCastDomainMessage(newGetNumberMessage(),false);
intresult=++lastGeneratedNumber;
domain.syncCastDomainMessageProcessed();
returnlastGeneratedNumber;
}
publicvoidprocessCastMessage(inGroupMemberIdsender,inMessagemsg)
{
if(msginstanceofGetNumberMessage){
++lastGeneratedNumber;
}
}
}
Al solicitarse un nmero, se enva el mensaje al grupo, comunicndole al
dominio que no se emplea el procesado normal. En el procesado normal, tal
como lo define SenseiGMS, todos los mensajes se reciben a travs de
processCastMessage. Si no se emplea procesado normal, el mensaje que una
rplicaenvanolorecibe.
Cuando la operacin de envo del mensaje vuelve, puede procesarse el servicio,
incrementando simplemente el valor de la variable lastGeneratedNumber que
almacenaelltimonmerodado.
Trasprocesarlo,yhaberalmacenadoelvaloradevolveralcliente,secomunicaal
dominio que el mensaje ha sido procesado. Con esta comunicacin se indica al
dominioquesepuedeprocesarelsiguientemensajedelgrupo,silohubiera.
Elsiguientelistadomuestraelcdigoasociadoalasegundaalternativa.
publicclassNumberGenerator:...
{
DomainGroupHandlerdomain;
intlastGeneratedNumber;
...
publicintgetNumber()
{
domain.syncCastDomainMessage(newGetNumberMessage(),true);
returnlastGeneratedNumber;
}
publicvoidprocessCastMessage(inGroupMemberIdsender,inMessagemsg)
{
if(msginstanceofGetNumberMessage){
SenseiDomains 198
++lastGeneratedNumber;
}
}
}
Al solicitarse un nmero en getNumber, se enva el mensaje al grupo,
comunicndolealdominioqueseempleaelprocesadonormal.
El mensaje se recibe entonces a travs del procedimiento normal, en
processCastMessage. No hay diferencia entre la recepcin de un mensaje propio
odeotrarplica,seincrementaigualmentelavariablelastGeneratedNumber.
Cuando processCastMessage finaliza, se completa el bloqueo de
syncCastDomainMessageengetNumber.Elvalorquedevuelvealclienteeselque
tieneenesemomentolastGeneratedNumber.
La segunda alternativa requiere menos cdigo, aunque esa reduccin es muy
pequea. Sin embargo, esta segunda solucin es incorrecta, pues el manejo de
threads impide saber si el desbloqueo sobre syncCastDomainMessage en getNumber
seproduceinmediatamente.Puededarseelcasodequeseproceseanunsegundo
mensaje GetNumberMessage que modificara el valor de lastGeneratedNumber,
producindose un resultado errneo. Es posible que la clase defina valores
temporales para corregir este error pero, en ese caso, resulta ms fcil emplear la
primeraalternativa.
Puesto que la invocacin de syncCastDomainMessageProcessed implica que el
dominio est bloqueado esperando a que la aplicacin procese un mensaje, es un
error invocarla en caso contrario, lo que se traduce en la excepcin
SyncCastDomainMessageProcessedException,definidasimplementecomo:
exceptionSyncCastDomainMessageProcessedException
{
};
Debe notarse que, puesto que DomainGroupHandler implementa la interfaz
GroupHandler, tambin soporta la operacin bsica de envo de mensajes sin
bloqueo:booleancastMessage(inMessagemsg).
10.8.Implementacin
La interfaz pblica de SenseiDomains que se ha definido en las secciones
anteriores,cubrelassiguientesespecificaciones:
DomainExceptions.idl:excepcionesgenricasdeldominio.
DomainMessage.idl:definicinbsicademensajededominio.
Properties.idl:soportedepropiedades.
SenseiDomains 199
DomainGroupHandler.idl:definicindedominio.
Monitor.idl:soportedeconcurrencia,medianterplicasytransacciones.
StateTransfer.idl:soportedetransferenciadeestado.
SubgroupsHandler.idl:gestindecomponentes.
Adems, InternalDomainMessages.idl incluye todas las definiciones
empleadasinternamenteporSenseiDomainsperoquedebenserdefinidasanivelde
interfaz. Estas definiciones incluyen losmensajesinternosyestructurasempleadas
paralatransferenciadeestado.
SenseiDomains soporta todos los algoritmos de transferencia de estado
desarrolladosenloscaptulosanteriores,apesardequeelusodetransaccioneses
slo compatible con el caso ms simple. De la complejidad de estos algoritmos,
sumada al amplio conjunto de facilidades asociadas al concepto de dominio, se
deduce la dificultad de la implementacin de SenseiDomains: tanto en complejidad
comoentamao(oeldelasclasesqueloimplementan),esvariasveces
8
superiora
SenseiGMS.
ElcaptuloanteriordefinilametodologaqueSenseiDomainsimplementa;sin
embargo, hay detalles de esta implementacin no directamente especificados en la
metodologa y aspectos de la metodologa no recogidos en la implementacin. Por
ejemplo, la balanza de carga en la eleccin de coordinadores de transferencia
empleandopesosdefinidosporlaaplicacinesunafacilidadaadida.
Por otra parte, en SenseiDomains la posesin de un monitor no afecta a la
transferenciadeestado.Comosecomprob,unarplicaquerealizaunatransaccin
no puede transferir su estado hasta concluir esa transaccin. Aunque esta
imposibilidad se podra eliminar complicando los algoritmos de tranferencia de
estado,setratadeunapropiedadconveniente:puestoquelatransaccinsuponela
adquisicin de un monitor que puedebloquearaotrasrplicas,esconvenienteque
termine esa transaccin y ese bloqueo cuanto antes, lo que se facilita al no
asignrselelatareaadicionaldecoordinarunatransferenciadeestado.Eldiseode
SenseiDomains permite inhibir la transferencia sobre miembros que realizan una
transferencia y, aunque la implementacin actual simplemente retrasa el comienzo
de esa transferencia hasta que la transaccin termina, es factible trasladar esa
coordinacin a otro miembro delgrupo.Sinembargo,nohayningunaalteracinen
el proceso de transferencia por el hecho de que un miembro posea un monitor, a
pesardequebloqueaigualmentealasdemsrplicas.
El motivo de esta diferencia es que, en SenseiDomains, un monitor es un
componentemsyeldominionotieneconocimientodelestadodecadacomponente.
8
La especificacin JavaRMI de SenseiDomains define cinco veces ms tipos que la de
SenseiGMS. La implementacin de los algoritmos de SenseiDomains emplea dos veces y media ms
lneasdecdigo(excluyendocomentarios)queenSenseiGMS.
SenseiDomains 200
Con el diseo actual, sera necesario que el dominio verificara su composicin de
componentesyobtuvieradelosidentificadoscomomonitoressuestadodebloqueo.
ObienquelainterfazDomainGroupHandlerincluyerafuncionalidadquepermitieraa
los monitores informar de su estado pero, al ser una interfaz pblica, no habra
forma de comprobar la consistencia de los accesos a esa funcionalidad,
comprometiendolaconsistenciadeldominio.
Una alternativa al diseo sera que la implementacin de monitores se
realizaraeneldominiomismo,talcomoocurreconlastransacciones,ofreciendoen
su interfaz las operaciones lock y unlock. Esta aproximacin empleara cualquier
componentecomomonitor,deunaformasimilaraJava,dondetodoslosobjetosson
monitores
9
. Sin embargo, la implementacin implicaba una fuerte carga de trabajo
sobreeldominio,altenerquemantenerelestadodecadacomponenteensufaceta
de monitor: como un monitor emplea mensajes no transaccionables, su
transferencia de estado es ms costosa de realizar, coste que se transferira al
dominio,implicandounpeorrendimientogeneral.
Por ltimo, la base de esta metodologa es la factorizacin de un servidor en
componentes, para facilitar su replicacin. Este servidor reside inicialmenteenuna
mquina dada, aunque puede emplear otros componentes externos como, por
ejemplo, un servicio de archivo, que residan en esa misma mquina o en otra
cualquiera.Aldividirelservidorencomponentes,elmodelodeldominioasume,por
9
Es discutible la relacin entre objeto y monitor en Java, pues en puridad el objeto contiene un
monitor,noesunmonitor(problemadedelegacinfrenteaherencia).
MquinaA
Figura10.3.Modelobsico dedominio
Dominio ComponenteA
ComponenteB
ComponenteZ
ComponenteN
ServicioS1
MquinaB
ServicioS8
DominioD
ComponenteA
ComponenteB
ComponenteZ
ComponenteN
SenseiDomains 201
extensin, que los componentes residen en una nica mquina, y la interaccin
entre el dominio y los componentes es local. La figura 10.3 muestra este modelo,
donde un dominio y sus componentes residen en una mquina dada, pudiendo
accederaotrosdominiosyserviciosocomponentesenesauotrasmquinas.
Apesardeestaideainicialdemodelo,eldominiodefinesuinteraccinconlos
componentesmedianteunainterfazCORBA,porloquenoesprecisoquesurelacin
sea local: un dominio puede componerse de componentesesparcidospordiferentes
mquinas, como muestra la figura 10.4. En la definicin JavaRMI, la relacin se
definemedianteinterfacesremotos,porloquedisponedelamismaflexibilidad.
10.9.Conclusiones
SenseiDomains es un sistema que define y soporta un modelo de replicacin
basado en componentes, facilitando la gestin y empleo de componentesreplicados
para as poder disear servicios tolerantes a fallos a alto nivel. Estos servicios an
estn basados en el modelo de sincrona virtual pero se les ocultan los detalles de
bajo nivel asociados al modelo, como el manejo de vistas o el uso de primitivas de
comunicaciones basadas en mensajes, que se relegan a la implementacin de los
componentes.
SenseiDomains no implementa directamente el modelo de sincrona virtual,
precisadeunsubstratodecomunicacionesquelosoporte.Elsoportequeempleaes
SenseiGMS, pero limitando sus dependencias a su interfaz, de tal modo que la
MquinaA
Figura10.4.Modeloextendido dedominio
ComponenteA
ComponenteB
MquinaB
Mquina C
ComponenteZ
ComponenteN
Dominio
SenseiDomains 202
implementacinpuedamigrarseconfacilidadaotrossistemasdecomunicacionesen
grupo, de acuerdo con la filosofa de SenseiGMS. Al igual que ste, SenseiDomains
soporta CORBA y JavaRMI, con una interfaz totalmente equivalente entre ambos y
unaimplementacincomndelosalgoritmos.
La metodologa que soporta SenseiDomains define unaextensafuncionalidad,
incluyendounatransferenciadeestadoflexible,elempleodepropiedades,controlde
concurrenciamediantemonitores,soportedetransacciones,etc.Laimplementacin
se realiza de tal manera que no se afecte negativamente, en dificultad de uso o en
rendimiento,aundominioquenonecesiteunafuncionalidaddada.
Lafactorizacindeservidoresencomponentesesespecialmenteventajosasise
disponedeimplementacionesyapreparadasdeesoscomponentes.SenseiUMAesla
parte de este proyecto que define una librera de contenedores replicados, como
listas,pilas,etc.Estoscomponentesdebenseranmanejadosconjuntamente,tarea
especfica del concepto de dominio, que evita, adems, los problemas de acceso
concurrentemediantetransaccionesymonitores,implementadosenSenseiDomains
deacuerdoalametodologadesarrollada.
Adems, SenseiDomains implementa facilidades necesarias internamente por
esos componentes, fundamentalmente la transferencia de estado y los patrones de
sincronizacindemensajes.
La metodologa expuesta en el captulo anterior tambin contempla la
generacin automtica de componentes replicados. Las herramientas necesarias
para esta generacin son independientes del concepto de dominio y no estn
integradasenSenseiDomains.
EstecaptulonohaejemplificadoelusodeSenseiDomains.Laraznesqueel
siguiente servicio desarrollado en Sensei, el servicio de localizacin de miembros,
estconstruidodeacuerdoaestemodelodecomponentes,empleandogranpartede
las facilidades soportadas por SenseiDomains. Este servicio se denomina
SenseiGMNS, y su funcionamiento e implementacin se detallan en el siguiente
captulo,queesporlotantounejemplorealdeaplicacindeSenseiDomains.
SenseiGMNS 203
Captulo11-SENSEIGMNS
ElmodelodesincronavirtualdefineunservicioGMSdepertenenciaagrupos
cuyafuncionalidadsebasaendosoperaciones:inclusinyexclusindeunmiembro
en un grupo. SenseiGMS no define ninguna operacin pblica para la creacin de
grupos, y esta tarea se delega a SenseiGMNS, que constituye, consecuentemente,
unaparteintegraldeSensei.
ElserviciofundamentalqueSenseiGMNSofreceeslagestinbsicadegrupos,
permitiendo crearlos o extenderlos, supliendo as la funcionalidad no presente en
SenseiGMS. Al emplear este servicio, la aplicacin debe decidir si desea crear o
extender un grupo, y en este ltimo caso, tiene que suministrar un miembro del
grupoenelquequiereincluirse.
Para facilitar esta gestin de grupos, SenseiGMNS implementa tambin un
serviciodedirectorio,permitiendomanejarlosgruposenbasealosnombresquese
les asigna. En este caso, una aplicacin suministra exclusivamente el nombre del
grupo en el que quiere incluirse y el servicio decide, en base a la informacin que
mantiene, si se trata de un grupo nuevo que debe crearse o de un grupo quedebe
extenderse.EsteserviciodanombreaSenseiGMNS,acrnimodelassiglaseningls
deGroupMembershipNamingService.
AdemsdedescribirlafuncionalidaddeSenseiGMNS,estecaptulomuestrael
empleodelametodologasoportadaporSenseiDomains,pueslaimplementacinse
realizaempleandocomponentesdinmicos.
SenseiGMNS 204
SenseiDomainssediseconindependenciadelsubstratodecomunicaciones
empleado.SenseiGMNS,sinembargo,estligadoaSenseiGMSynotienesentidosin
ste. Otros sistemas de comunicaciones en grupo implementan ambas
funcionalidades en un solo servicio, por lo que es innecesario el empleo de
SenseiGMNSenelcasodeutilizarSenseiDomainssobreestosotrossistemas.
11.1.Gestinbsicadegrupos
Un sistema de comunicaciones en grupo fiables debe soportar la gestin de
grupos de rplicas, permitiendo a un servidor crear un nuevo grupo, extenderlo, o
excluirse del mismo. El modelo de sincrona virtual no especifica cmo debe
realizarseesagestin;Ensemble,porejemplo,larealizaidentificandocadagrupocon
un nombre y empleando este nombre en la operaciones de creacin y extensin de
grupos(ambasfuncioneslasimplementaconunanicafuncinjoin).
La interfaz pblica de SenseiGMS no incluye ninguna operacin con este
propsito,aunquesseincluyeenlainterfazprivada,sobreSenseiGMSMember:
{
...
};
Elenfoquetomadoesinterpretarcadamiembrodeungrupocomounpuntode
acceso al grupo. Una rplica debe obtener de alguna manera una referencia a otra
rplica para incorporarse al grupo al queestaltimapertenece.Noesunproblema
que una rplica pertenezca a varios grupos pues, en ese caso, tiene diferentes
referenciasSenseiGMSMemberparacadagrupo.
Para que un servidor pueda pertenecer a un grupo, debe implementar la
interfaz GroupMember; al incorporarse al grupo, obtiene una referencia
GroupHandler con la que accede a las operaciones en grupo. La relacin entre
interfacessemuestraenlafigura11.1:
El servidor implementa la interfaz GroupMember, mediante la cual obtiene los
eventosdegrupo.
El servidor obtiene una referencia GroupHandler, con la que realiza las
comunicacionesalgrupo.
La interfaz GroupHandler obtenida es una instancia de SenseiGMSMember. El
anillo de comunicaciones del grupo en Sensei se forma con las instancias
SenseiGMSMemberdesusmiembros.
SenseiGMNS 205
Por lo tanto, todo miembro del grupo debe instanciar la interfaz
SenseiGMSMember, con la que pasa a formar parte del anillodecomunicacionesde
su grupo. Es perfectamente posible que un servidor en una mquina determinada
emplee una instancia SenseiGMSMember localizada en una mquina diferente, pero
introduceunnuevopuntodeerror,reduciendolatoleranciaafallos.Porejemplo,la
figura11.2visualizaunescenariodondeunaaplicacinreplicadacondosservidores
mantiene las instancias SenseiGMSMember en la misma mquina. Si esta mquina
se cae, no slo se cae el servidor que alberga, sino que el otro servidor pierde
igualmente su funcionalidad. La aplicacin no era tolerante a fallos en la mquina
cada,loquehasupuestosuprdidadeservicio.
Elrazonamientorealizadoimplicaquecuandounservidorsolicitasuinclusin
a otro servidor de un grupo dado, ste debe crear una instanciaSenseiGMSMember
que resida en la mquina y proceso del primer servidor. En lugar de extender la
interfaz GroupMember con una operacin callback que realice este cometido,
SenseiGMNSdefineunainterfazespecficaGroupHandlerFactory:
exceptionGroupHandlerFactoryException{};
interfaceGroupHandlerFactory
{
GroupHandlercreate()raises(GroupHandlerFactoryException);
};
Unservidorqueaccedeaunmiembroparaunirseasugrupo,suministrauna
instancia GroupHandlerFactory que el miembro destino emplea para crear la
instanciaGroupHandler,lacualresultaahoralocalalnuevomiembro.
Figura11.1.Relacin deinterfacesenSenseiGMS
Servidor
replicado
Interfazdel
servidor
GroupMember
Relacinde herencia
Implementa
GroupHandler
SenseiGMSMember
Relacinde herencia
Usa,paraaccederalgrupo
Grupo
Contiene,elgrupoloforman
InstanciasSenseiGMSMember
Usa,elgrupoenvasuseventos
alGroupMember
Comunicaciones
ALgrupo
Comunicaciones
DELgrupo
SenseiGMNS 206
Esta lgica supone que toda aplicacin tolerante a fallos debe ser capaz de
crearunobjetodetipoSenseiGMSMemberydeimplementar,consecuentemente,los
algoritmos de comunicaciones en grupo desarrollados en el captulo 8, cuando
explicamos SenseiGMS. Una alternativa es emplear la funcionalidad de CORBA de
transferenciadeobjetosporvalorparaestefin:elservidorGMNSpuedesuministrar
el objeto con funcionalidad SenseiGMSMember, para lo que definimos la siguiente
entidad:
valuetypeGroupHandlerFactoryCreator
{
GroupHandlerFactorycreate(inGroupMembermember)
raises(GroupHandlerFactoryException);
};
De esta manera, un miembro accede al servicio SenseiGMNS, obteniendo un
objeto GroupHandlerFactoryCreator. Su definicin es valuetype en lugardeinterface,
lo que garantiza que esta referencia GroupHandlerFactoryCreator reside localmente
en el espacio de memoria del miembro que la solicita
10
. A continuacin, este
miembro crea un objeto GroupHandlerFactory suministrando una referencia a su
10
Esta funcionalidad est directamente soportada en Java, que permite transferencia no slo de
datos, sino tambin de cdigo. As, la interfaz JavaRMI de SenseiGMNS define el tipo
GroupHandlerFactoryCreator como una extensin de java.util.Serializable, mientras que todo tipo
remotoextiendejava.rmi.Remote.
Mquina Vigo
Mquina Madrid
Figura11.2.Creacin errneadeinstanciasGroupHandler
ServidorA
GroupHandlerdelservidorA
GroupHandler
SenseiGMSMember
GroupHandlerdelservidorB
GroupHandler
SenseiGMSMember
ServidorB
Grupo:
anillo
Usodelgrupo
porA(local)
Usodelgrupo
porB(remoto)
SenseiGMNS 207
interfaz GroupMember, y ese objeto ser empleado en las operaciones decreacino
extensindelgrupo.
La interfaz bsica de SenseiGMNS es GroupMembershipBasicService, definida
enGroupMembershipNamingService.idldelasiguienteforma:
exceptionInvalidGroupHandlerException{};
exceptionInvalidGroupHandlerFactoryException{};
interfaceGroupMembershipBasicService
{
GroupHandlercreateGroup(inGroupHandlerFactorytheFactory)
raises(InvalidGroupHandlerFactoryException,
GroupHandlerFactoryException);
GroupHandlerjoinGroup(inGroupHandlergroup,
inGroupHandlerFactorytheFactory)
raises(InvalidGroupHandlerException,
InvalidGroupHandlerFactoryException,
GroupHandlerFactoryCreatorgetFactoryCreator();
};
createGroup: crea un grupo a partir de un GroupHandlerFactory. La instancia
GroupHandlerquesedevuelvesecreadeformalocalenelmiembroqueinvocala
operacin,ynolocalalservicioGMNS.
joinGroup:extiendeelgrupoidentificadoporlareferenciaGroupHandlerdadacon
unnuevomiembro,especificadomediantelareferenciaGroupHandlerFactory.
getFactoryCreator: devuelve la instancia GroupHandlerFactoryCreator, con la que
es posible crear los objetos GroupHandlerFactory empleados en las dos
operacionesanteriores.
El escenario asociado resulta complejo para asegurar que el anillo lgico de
comunicaciones de Sensei se integra por componentes residentes fsicamente en la
mquina y proceso que representan. Resumiendo, lospasosrequeridosparaincluir
unmiembroenungruposon:
El futuro miembro del grupo accede al servicio GMNS y obtiene mediante la
operacin getFactoryCreator un objeto del tipo GroupHandlerFactoryCreator, que
residelocalmenteenlamquinayprocesodeesemiembro.
Este miembro emplea el objeto GroupHandlerFactoryCreator para crear una
instanciadelainterfazGroupHandlerFactoryqueexiste,porlotanto,localmente.
ElmiembroaccededenuevoalservicioGMNS,estavezalaoperacinjoinGroup,
pasandoelobjetoGroupHandlerFactory.
El servidor GMNS accede (remotamente) al objeto GroupHandlerFactory, para
crearelGroupHandlerenelprocesodelfuturomiembro,ydevuelvelareferencia
creadaaesemiembro,yapertenecientealgrupo.
SenseiGMNS 208
La interfaz del servicio creado para gestionar los grupos no ofrece, sin
embargo, ninguna funcionalidad para obtener referencias a otros miembros, que
deben ser localizadas por la aplicacin. El servicio de directorio de SenseiGMNS
cubreestafuncionalidad.
11.2.Serviciodedirectorio
Elserviciodedirectoriomantienereferenciasalosmiembrosexistentesenun
grupo, al que identifica mediante un nombre. Empleando esta funcionalidad, un
miembro puede incluirse en un grupo especificando su nombre y el servicio se
encargadecrearunnuevogrupoo,siyacontienereferenciasaotrosmiembrosenel
mismogrupo,deextenderlo.
La utilidad de este servicio no se limita a la gestin de grupos. Un cliente
puedeemplearloparaobtenerlareferenciadeunmiembrodeunservidorreplicado,
adiferenciadelserviciomostradoenlaanteriorseccin.
Desde la perspectiva del grupo, cada miembro debe implementar la interfaz
GroupMember. Pero estos miembros forman, adems, parte de una aplicacin que
ofrece una interfaz especfica a sus clientes. El servicio de directorio almacena
referencias de los miembros a ambas interfaces y, por ello, se define la interfaz
ReplicatedServer,sinfuncionalidadpropia,quedebeserextendidaporlainterfazde
cliente:
interfaceReplicatedServer
{
};
Elserviciodedirectoriosedefinemediantelasiguienteinterfaz:
interfaceGroupMembershipNamingService
{
GroupHandlerfindAndJoinGroup(instringgroupName,
inGroupHandlerFactorytheFactory,
instringmemberName,
inReplicatedServerclientsReference)
raises(sensei::middleware::domains::MemberStateException,
voidleaveGroup(instringgroupName,inGroupHandlermember);
ReplicatedServersListgetGroup(instringgroupName)
raises(sensei::middleware::domains::MemberStateException);
ReplicatedServergetGroupServer(instringgroupName,instringmemberName)
SenseiGMNS 209
ReplicatedServergetValidGroupServer(instringgroupName)
};
getFactoryCreator:definelamismafuncionalidadqueenelcasodelaoperacin
homnimaenGroupMembershipBasicService.
findAndJoinGroup:creaoextiendeungrupo,alqueseidentificaporunnombre.
Elmiembrodebesuministrarunnombre,unainterfazdeclienteyunainstancia
GroupHandlerFactory, usando la misma filosofa mostrada en
GroupMembershipBasicService para crear los objetos localmente al miembro que
extiendeocreaelanillo.
leaveGroup: el miembro identificado por la instancia GroupHandler asociada es
expulsadodelgrupo.
getGroup: devuelve las referencias de todas las rplicas del grupo especificado,
sincomprobarsesilasrplicassonanvlidas.Lasreferenciasdevueltassonlas
interfacesdeclienteregistradas.
getGroupServer:devuelvelareferenciaaunservidorespecficoenelgrupodado.
Lareferenciadevueltaeslainterfazdeclienteregistrada.
getValidGroupServer: devuelve la referencia a un servidor especfico en el grupo
dado,comprobndosepreviamentequeelservidorestodavavlido.Lareferencia
devueltaeslainterfazdeclienteregistrada.
El servicio GMNS comprueba peridicamente las rplicas que contiene,
eliminando aquellas que han cado o hayan sido excluidas del grupo sin haber
empleadoleaveGroup.
Si el servicio bsico de SenseiGMNS es esencial para la creacin de grupos,
esteserviciodedirectorionoloes.As,unmiembroqueseincluyeenungruposin
emplear este servicio de directorio no es registrado y no puede ser utilizado para
extender elgrupoalquepertenece.Lasconsecuenciassonposiblesinconsistencias
enaplicacionesquenoempleendeformauniformeelserviciobsicooelserviciode
directoriosdeSenseiGMNS.
Paraqueesteservicioseaefectivo,debeserporsmismotoleranteafallospor
lo que se ha diseado como un servidor replicado, diseo que detallamos a
continuacin como ejemplo de uso de la metodologa que SenseiDomains
implementa.
SenseiGMNS 210
11.3.DiseodeSenseiGMNSencomponentes
dinmicos
Laseccin8.3introdujolasbasesdediseodeunserviciodedirectoriocomo
ejemplo de uso de SenseiGMS. En aquel caso, el diseo se basaba en un nico
componenteGMNSdataquealmacenabalainformacinareplicarenelservicio.Este
componentenosoportabaaccesosconcurrentes,conloquevariasrplicasnopodan
actualizarlosimultneamente.
El diseo real de un servidor GMNSreplicadolohemosrealizadoextendiendo
el modelo del mismo servidornoreplicado.Sobreesteservicionotoleranteafallos,
unaimplementacinlgicasebasara[figura11.3]enuncontenedortipodiccionario
quecontendracomoclaveslosnombresdelosgruposycomovaloreslainformacin
asociada a stos. La informacin necesaria para un grupo puede, a su vez,
representarseconuncontenedortipolistadondecadaelementoeslainformacinde
una rplica, compuesta por sus referencias GroupHandler y ReplicatedServer, y el
nombreasignado.
Con esta estructura de datos, el diccionario estara inicialmente vaco; al
crearse un nuevo grupo, se crea una nueva instancia del tipo lista empleado para
almacenar la informacin de las rplicas de un grupo, y se introduce un par
{nombre, lista} en el diccionario. A continuacin, se crea una instancia de la clase
empleada para almacenar la informacin de una rplica, que se inserta en la lista
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
degrupo
Lista
derplicas
Nombre
degrupo
Figura11.3.Estructura dedatosenunservidorGMNSnoreplicado
Informacin
GMNS
Diccionario
depares
{nombre degrupo,
Informacin
degrupo}
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
derplica
Nombre
GroupHandler
ReplicatedServer
Informacin
degrupo
Lista
derplicas
Nombre
degrupo
SenseiGMNS 211
dada. Por consiguiente, el diccionario es el nico componente inicial, todos los
demssecreandinmicamente.
AltransformarelservidorenunoreplicadobajoCORBA,seranecesariodefinir
primero la entidad que almacena la informacin de una rplica, para lo que
empleamoslastructMemberInfo:
structMemberInfo
{
stringname;
ReplicatedServerpublicReference;
};
typedefsequence<MemberInfo>MemberInfoList;
ElcontenedorqueguardalasinstanciasMemberInfoesunalista,porloquese
podra implementar con el contenedor replicado estndar ReplicatedList de
SenseiUMA. Sin embargo,SenseiUMA,adiferenciadelosdemssistemasenSensei
sedefinedeformadiferenteenCORBAyJavaRMI,puesensuimplementacinbajo
JavaRMI intenta integrarse con tipos ya definidos, como java.util.iterator, etc. Por
esta razn, SenseiGMNS se implementara tambin diferentemente en ambas
arquitecturas, en contra de lo deseado. Adems, implicara una dependencia de
SenseiGMNS en SenseiUMA, dependencia que preferimos evitar para minimizar el
cdigoestrictamentenecesarioenlaimplementacindeSenseiGMNS.
Como consecuencia, definimos un contenedor del tipo lista replicada
especialmente para este caso. El principal beneficio asociado es que en lugar de
emplear tipos genricos, la lista se define como un contenedor de instancias
concretasMemberInfo:
interfaceSetMemberInfo:ExtendedCheckpointable,SetMemberInfoObservable
{
booleanadd(inMemberInfomember)
booleanremove(inMemberInfohandler)
MemberInfoget()
MemberInfoListtoArray()
};
El tipo de contenedor es set, una lista que no acepta valores duplicados.
Puestoqueestecontenedornotieneunusogeneral,sedefinenslolasoperaciones
requeridas: insertar y borrar un elemento, que devuelven un valor booleano que
indica el xito de la aplicacin, y dos operaciones de acceso a los elementos
contenidos. Este acceso es tambin especfico y, en lugar de definirse una interfaz
SenseiGMNS 212
que itere sobre el contenido, al estilo de java.util.Iterator en Java, se emplean dos
operacionesbsicas:obtenerunelementoyobtenertodosloselementos.
La definicin de esta interfaz es ExtendedCheckpointable, luego el soporte de
transferencia de estado es bsico y la transferencia se efecta en un solo paso.
Adems,lainterfazextiendeSetMemberInfoObservable,quesedefinecomo:
interfaceSetMemberInfoObservable
{
voidaddObserver(inSetMemberInfoObserverobserver);
booleanremoveObserver(inSetMemberInfoObserverobserver);
};
Lafuncionalidadasociadaespermitirobservaralcontenedordado.Puestoque
este contenedor est replicado, cualquiera de los servidores GMNS puede
actualizarlo,yesasactualizacionesdebenreflejarseenlainterfazgrficadelservicio
[figura 11.4], lo que admite dos soluciones: interrogar peridicamente a los
contenedoressobresucontenidoorecibireventoscuandoseactualizan.Lasegunda
aproximacin es ms complicada, pero ventajosa. De hecho, SenseiUMA soporta
tambinestasegundaopcinenloscontenedoresdefinidos.
La observacin se realiza aplicando el patrn de observacin [Gamma95],
tambienconocidocomopatrndepublicacin/subscripcin:elcontenedorsedefine
como observable, permitiendo que todo elemento registrado, implementando una
interfazObserver,recibaloseventosdecambios.Estaltimainterfazsedefinepara
estecasoespecficocomo:
Figura11.4.InterfazgrficadeSenseiGMNS
SenseiGMNS 213
interfaceSetMemberInfoObserver
{
voidaddDone(inSetMemberInfoObservableobservable,inMemberInfomember);
voidremoveDone(inSetMemberInfoObservableobservable,inMemberInfomember);
};
La lista informa, por lo tanto, de cualquier adicin o borrado de elementos,
juntoconelelementodado.
Lamismalgicageneralseempleaparaeldiccionario,quesedefinemediante
lainterfazMapStringSet:
exceptionInvalidSetMemberInfo{};
typedefsequence<string>stringList;
interfaceMapStringSetObserver
{
voidclearDone(inMapStringSetObservableobservable);
voidputDone(inMapStringSetObservableobservable,
instringgroupName,
inSetMemberInfoset);
voidremoveDone(inMapStringSetObservableobservable,
instringgroupName,
};
interfaceMapStringSetObservable
{
voidaddObserver(inMapStringSetObserverobserver);
booleanremoveObserver(inMapStringSetObserverobserver);
};
interfaceMapStringSet:ExtendedCheckpointable,MapStringSetObservable
{
SetMemberInfoput(instringgroupName,inSetMemberInfoset)
raises(InvalidSetMemberInfo,
sensei::middleware::domains::MemberStateException);
SetMemberInforemove(instringgroupName)
SetMemberInfoget(instringgroupName)
stringListgetKeys()
};
SenseiGMNS 214
11.3.1.Implementacindeloscomponentes
Tras haber definido la interfaz de los componentes de SenseiGMNS, es
necesarioespecificarlosmensajesquelasrplicasintercambianycmosetransfiere
elestado.
MemberInfosedefinienOMG/IDLcomostruct:notienecomportamiento,slo
almacena los datos asociados. En el caso del componente SetMemberInfo, soporta
dos operaciones: add, remove. En lugar de definir dos mensajes, empleamos uno
solo,especificadocomo:
valuetypeSetMemberInfoChangedMessage:DomainMessage
{
publicMemberInfoinfo;
publicbooleanadd;
};
Estemensajecontienelainformacindelmiembroqueseaadeoelimina,yse
define como una especializacin de DomainMessage. No precisa de un tratamiento
especialdurantelastransferenciasotransacciones,porloquelaimplementacinno
debemodificarelvalordelcampounqueuedOnST(false)deDomainMessage.
El componente se define como ExtendedCheckpointable, luego es estado se
transfiere en un nico paso; en este caso, la informacin a transferir incluye los
datosdecadaunodeloscomponentesdelalista:
valuetypeSetMemberInfoState:State
{
publicsequence<MemberInfo>members;
};
La implementacin del componente la realizamos en Java; la clase asociada
necesitadosconstructoresdistintos:
SetMemberInfoImpl(intsubgroupId,DomainGroupHandlergroupHandler);
SetMemberInfoImpl(DynamicSubgroupInfodynamicInfo,DomainGroupHandlergroupHandler);
Constructoresttico.Empleadoencasoderegistrarelcomponenteestticamente
eneldominio,precisadeunaidentidaddecomponentepredefinidaydeldominio
aemplear.Tambinseutilizaparacrearcomponentesdinmicosendemanda,al
conocerseyasuidentidad.
Constructor dinmico. Empleado para crear dinmicamente un componente,
precisadelainformacinaenviaraotrasrplicas.
Elcomponenteimplementaunalista,porloqueempleainternamenteunalista
para almacenar los miembros; el tipo seleccionado es java.util.Set (implementado
mediante java.util.HashSet). El estado inicial de esta lista no incluye ningn
miembro,yseimplementanlasoperacionesdetransferenciacomo:
SenseiGMNS 215
publicsynchronizedStategetState()
{
returnfactory.createSetState(getMembers());
}
MemberInfo[]getMembers()
{
intsize=set.size();
MemberInfomembers[]=newMemberInfo[size];
if(size>0){
inti=0;
Iteratorit=set.iterator();
while(it.hasNext()){
members[i++]=(MemberInfo)it.next();
}
}
returnmembers;
}
publicsynchronizedvoidsetState(Statestate)
{
set.clear();
MemberInfomembers[]=((SetMemberInfoState)state).members;
intsize=members.length;
for(inti=0;i<size;i++){
addMemberInfo(members[i]);
}
}
synchronizedbooleanaddMemberInfo(MemberInfomemberInfo)
{
booleanret=set.add(memberInfo);
if(ret){
observersHandler.informPut(memberInfo);
}
returnret;
}
publicsynchronizedvoidassumeState()
{
set.clear();
}
assumeState:eliminacualquierelementodelalista.
SenseiGMNS 216
setState:aadecadaunodeloselementosdadosenlalistadeentrada.Paraello
emplea un mtodoaddMemberInfo,tambinempleadoenlaadicinposteriorde
miembros que, adems de incluirlo enlalista,informadeleventoalosposibles
observadores.
getState: emplea un objeto factory, capaz de crear el objeto middleware State,
tanto para JavaRMI, como para CORBA, con la informacin del miembro. Esta
informacin la obtiene de getMembers, que itera sobre los elementos de la lista,
devolvindolosenunarray.
El componente SetMemberInfo es un miembro de grupo, por lo que debe
reaccionar a los seis eventos del grupo. Slo es relevante el procesado de los
mensajesmultipunto:
publicvoidprocessPTPMessage(intparm1,Messageparm2){}
publicvoidinstallView(Viewparm1){}
publicvoidmemberAccepted(intid,GroupHandlerparm2,Viewparm3)
{
memberId=id;
}
{
freeResources();
}
publicvoidprocessCastMessage(intsender,Messagemessage)
{
if(messageinstanceofSetMemberInfoChangedMessage){
synchronized(this){
SetMemberInfoChangedMessagemsg=
(SetMemberInfoChangedMessage)message;
if(msg.add)
addMemberInfo(msg.info);
else
removeMemberInfo(msg.info);
}
}
}
En caso de recibir un mensaje SetMemberInfoChangedMessage, se aade o
elimina el miembro que contiene, segn sea el mensaje. Para ello, se emplea el
mtodo addMemberInfo, ya mostrado anteriormente, o removeMemberInfo que, dela
mismamanera,eliminaelmiembrodelalistaeinformaalosobservadores:
synchronizedbooleanremoveMemberInfo(MemberInfomemberInfo)
{
SenseiGMNS 217
MemberInfocontent=(MemberInfo)it.next();
if(ObjectsHandling.areEquivalent(memberInfo.handler,content.handler))
{
it.remove();
observersHandler.informRemove(memberInfo);
returntrue;
}
}
returnfalse;
}
En CORBA, dos referencias a un mismo miembro pueden ser distintas,porlo
que es necesario emplear mtodos CORBA especficos para realizar la comparacin
entre referencias. El objeto ObjectsHandling efecta esta comparacin de modo
transparenteparaCORBAyJavaRMI,permitiendoqueelmismocdigoseavlidoen
ambasplataformas.
La interfaz pblica del componente se implementa a continuacin, sin incluir
el tratamiento de errores. El cdigo es una implementacin directa del patrn de
sincronizacindemensajesenelcasodetenerquedevolverunvaloralcliente:
publicbooleanadd(MemberInfoinfo)throwsMemberStateException
{
booleanresult=false;
factory.castSetMessage(info,true);
result=addMemberInfo(info);
factory.syncMessageCompleted();
returnresult;
}
publicsynchronizedMemberInfoget()throwsMemberStateException
{
returnit.hasNext()?(MemberInfo)it.next():null;
}
publicbooleanremove(MemberInfoinfo)throwsMemberStateException
{
factory.castSetMessage(info,false);
result=removeMemberInfo(info);
returnresult;
}
publicsynchronizedMemberInfo[]toArray()
{
intsize=set.size();
SenseiGMNS 218
MemberInfo[]ret=newMemberInfo[size];
set.toArray(ret);
returnret;
}
Por consiguiente, las operaciones get y toArray se implementan sin
comunicaciones al grupo, y las operaciones add y remove implican el envo de un
mensajeysuprocesadoenelmismothreaddeenvo,devolviendoelresultadodela
operacin al cliente. Elcdigonecesarioparaimplementarelpatrndeobservacin
esirrelevanteynoloincluimosparanoextenderinnecesariamenteestaexplicacin;
elapndiceDcontieneelcdigocompletodeestaclase.
El componente MapStringSet sigue la misma lgica. Define los mismos
constructores, mismo tratamiento de eventos, etc. A continuacin se muestra la
definicindelosmensajesyelestado:
valuetypeMapStringSetPutMessage:DomainMessage
{
publicstringkey;
publicSubgroupIdvalue;
};
valuetypeMapStringSetRemoveMessage:DomainMessage
{
publicstringkey;
};
structMapStringSetEntry
{
stringkey;
SubgroupIdvalue;
};
valuetypeMapStringSetState:State
{
publicsequence<MapStringSetEntry>groups;
};
En este caso se definen dos mensajes distintos para las operaciones put y
remove,pueslainformacinasociadaesdiferente.
Es importante destacar que en las comunicaciones al grupo no se enva el
componente SetMemberInfo que contiene, sino la identidad de ese componente
replicado(ennegritaenelanteriorlistado),talcomoseharegistradoeneldominio.
Este tratamiento no es una optimizacin, sino una necesidad, pues cada rplica
debecontenerreferenciasdeloscomponentesqueinstancia,nodeloscomponentes
enlarplicaqueenvalainformacin.
SenseiGMNS 219
sta es precisamente la segunda razn por la que SenseiUMA es diferente en
JavaRMI y CORBA. Java soporta nativamente patrones de serializacinyesposible
especificarlamaneraenqueundeterminadoobjetoseserializa.Alserializarobjetos
del tipo GroupMember, se accede al dominio para obtener su identidad de
componente,queeslainformacinqueseenva.BajoCORBA,elcomponentepodra
verificar explcitamente si el objeto a enviar implementa la interfaz GroupMember,
pero esta solucin resulta insuficiente, al no cubrir objetoscomplejosqueincluyan
ensucomposicincomponentesreplicados.
Este componente implementa un diccionario o mapa, por lo que emplea
internamente el mismo tipo para almacenar elementos; java.util.Map (implementado
mediantejava.util.HashMap).ElapndiceDincluyeelcdigocompletodeestaclase,
y slo mostramos aqu el tratamiento de componentes replicados en el mtodo put,
queincluyeparaunnombredegrupouncomponenteSetMemberInfo,yenelmtodo
derecepcindemensajes,processCastMessage,ambossincomprobacinexhaustiva
deerrores:
publicSetMemberInfoput(Stringgroup,SetMemberInfoset)
throwsInvalidSetMemberInfo,MemberStateException
{
SetMemberInforesult=null;
intsubgroupId=groupHandler.getSubgroupId(set);
if(subgroupId==Consts.INVALID_SUBGROUP){
thrownewInvalidSetMemberInfo();
}
factory.castMapPutMessage(group,subgroupId);
result=doPut(group,set);
returnresult;
}
{
if(messageinstanceofMapStringSetPutMessage){
MapStringSetPutMessagemsg=(MapStringSetPutMessage)message;
GroupMembersubgroup=groupHandler.getSubgroup(msg.value);
SetMemberInfoset=GMNSnarrower.toSetMemberInfo(subgroup);
if(set!=null){
doPut(msg.key,set);
}
}
...
}
SetMemberInfodoPut(Stringgroup,SetMemberInfoset)
{
SenseiGMNS 220
SetMemberInforet=null;
Objectobj=null;
synchronized(this){obj=map.put(group,set);}
if(obj!=null){
ret=GMNSnarrower.toSetMemberInfo(obj);
observersHandler.informRemove(group,ret);
}
observersHandler.informPut(group,set);
returnret;
}
Al procesar una operacin put, se comprueba que el componente insertado es
vlido (que est registrado en el dominio). En la estructura de datos interna se
guarda la referencia al componente replicado, aunque la informacin que se
envaalgrupoessuidentidad.
Al recibir el mensaje asociado a la operacin put, se obtiene el componente
replicadoapartirdelaidentidaddecomponenterecibida.
AmbosmtodosdeleganenlaoperacindoPutparainsertarefectivamenteelpar
{nombre,componente}que,adems,comunicaeleventoalosobservadores.
11.3.2.Integracindecomponentes
Al introducir informacin relativa a un nuevo grupo, el servidor GMNS debe
crear un componente dinmico SetMemberInfo, cuya creacin debe propagarse a
cada rplica GMNS, donde se instancia la rplica de ese componente dinmico. El
servidorGMNSquecreaelgrupoempleauncdigoqueenesenciaes:
SetMemberInfoImplsetImpl=newSetMemberInfoImpl(Consts.noInfo,domainHandler);
SetMemberInfoset=setImpl.theSetMemberInfo();
map.put(groupName,set);
set.add(newMemberInfo(groupHandler,memberId,clientReference));
Se crea el componente empleando el constructor dinmico, que precisa de la
informacinqueseenvaalasdemsrplicassobreelcomponentequesecrea.
Enesecasoconcretonoseenvaningunainformacin.Cuandoestecomponente
secrea,tambinlohacensusrplicasenlosotrosservidoresGMNS.
LasegundalneaenelanteriorlistadoesnecesariaporladiferenciacinCORBA
entre servidor y servant
11
[OMG98]. Simplemente activa el servidor, obteniendo
una referencia vlida al mismo. En el caso de JavaRMI, exporta el servidorpara
serpblicamenteaccesible.
11
En esencia, servant es la implementacin en un lenguaje determinado de lafuncionalidaddel
servidor.Esprecisoactivar(encarnar)elservantparaobtenerelservidor.
SenseiGMNS 221
Se inserta el set en el diccionario, con el nombre dado al grupo. Puesto que el
componentediccionarioestreplicado,susrplicasinsertansimultneamenteel
setconelmismonombre.Elsetqueinsertannoeselexistenteenesteservidor,
sinoelquehayasidocreadoenelrespectivoservidor.
Finalmente, se inserta la informacin del grupo en el set. De nuevo, esta
operacinsepropagaalasdemsrplicas,deacuerdoconlaimplementacinde
SetMemberInfo,conloquelainformacinesconsistenteencadarplica.
Cada rplica del servicio GMNS debe ser capaz de crear componentes
dinmicos,porloqueesnecesarioimplementarlainterfazDynamicSubgroupsUser:
classMyDynamicSubgroupsUserextendsDynamicSubgroupsUserBaseImpl
{
publicMyDynamicSubgroupsUser()throwsException
{
}
publicGroupMemberacceptSubgroup(intid,DynamicSubgroupInfoinfo)
{
try{returnnewSetMemberInfoImpl(id,domainHandler).theSetMemberInfo();}
catch(Exceptionex){returnnull;}
}
publicGroupMembersubgroupCreated(intcreator,intid,DynamicSubgroupInfoinfo)
{
try{returnnewSetMemberInfoImpl(id,domainHandler).theSetMemberInfo();}
catch(Exceptionex){returnnull;}
}
publicvoidsubgroupRemoved(intremover,intid,DynamicSubgroupInfoinfo)
{
}
}
Cuando se recibe cualquiera de los dos eventos de creacin de componente, se
creaunobjetoSetMemberInfo.Puestoqueeselnicotipodeobjetoquesecrea,
no hace falta que el parmetro DynamicSubgroupInfo contenga informacin
especfica.
Noesprecisohacernadacuandoelcomponenteseelimina(unaimplementacin
C++hubieraprecisadoladestruccindelservant).
Porltimo,lainstanciadelaanteriorclasedeberegistrarseeneldominio,que
debe crearse con las caractersticas deseadas. Tambin deben registrarse en el
dominioloscomponentesestticos:
(A)domainHandler=newDomainGroupHandlerImpl().theDomainGroupHandler();
(B)domainHandler.setBehaviourMode(
BehaviourOnViewChanges.MembersOnTransferExcludedFromGroup);
domainHandler.setDynamicSubgroupsUser(
SenseiGMNS 222
newMyDynamicSubgroupsUser().theDynamicSubgroupsUser());
domainHandler.setDomainGroupUser(...);
(C)GroupMonitorImplmonitorImpl=
newGroupMonitorImpl(Consts.MONITOR_SUBGROUP,domainHandler);
MapStringSetImplmapImpl=
newMapStringSetImpl(Consts.MAP_SUBGROUP,domainHandler);
map=mapImpl.theMapStringSet();
(D)monitorImpl.register();
mapImpl.register();
LanicaoperacinenelgrupoAcreaeldominio.
Las siguientes tres lneas en el grupo B definen las caractersticas del dominio,
incluyendoelregistrodelgestordecomponentesdinmicosquepermiteemplear
estetipodecomponentes.
A continuacin, se crean los componentes estticos, que en este caso es un
monitor,empleadoparalastransacciones,yundiccionario.
Finalmente, las dos operaciones del grupo D registran los componentes en el
dominio.
11.3.3.Implementacindelosalgoritmos
Tras haberse implementado los componentes replicados y creado el dominio
paragestionarlosdinmicamente,podemoscentrarnosenlalgicadeaplicacin.La
operacin fundamental del servidor GMNS es la introduccin de un servidor en un
grupo,quetalvezseanecesariocrear.
Paraestaoperacindefinimosdosoperacionesbsicas:
joinGroup: incluye un miembro en un grupo. Si el grupo no existe, la operacin
devuelvefalse.
createGroup: crea un grupo e inserta el miembro especificado. Si el grupo ya
existe,laoperacindevuelvefalse.
Con este soporte, la operacin findAndJoinGroup se escribe, sin soporte de
errores,como:
...
booleanstop=true;
while(!stop){
stop=joiner.joinGroup(groupName,factory,memberId,reference);
if(!stop){
stop=creator.createGroup(groupName,factory,memberId,reference);
}
}
...
SenseiGMNS 223
Primeroseintentaextenderelgrupo;sinoseconsigue,seintentacrearlopero,
duranteesteintervalo,otroservidorpuedehabercreadoelmismogrupo,conloque
la creacin puedefallartambin,encuyocasoserepiteelproceso.Laalternativaa
este algoritmo es emplear un monitor que bloquee el acceso al diccionario a otras
rplicas, impidiendo que creen el mismo grupo. Sin embargo, la operacin join es
particularmente lenta, y esta aproximacin supone bloquear a todos los servidores
GMNS en cada operacin, incluso aquellos que pretenden acceder a grupos
diferentes.
La operacin createGroup debe emplear transacciones para evitar que dos
servidorescreenelmismogrupoalmismotiempo:
domainHandler.startTransaction(monitor);
SetMemberInfogroup=map.get(groupName);
if(group==null){
ret=createGroupSafely(groupName,factory,memberId,reference);
}
elseif(group.get()==null){
ret=addMemberSafely(group,factory,memberId,reference);
}
else{
ret=false;
}
domainHandler.endTransaction();
La creacin del grupo se protege con una transaccin en torno al monitor
registrado.
Seobtienedeldiccionariolainformacinasociadaalgrupoespecfico,queesuna
referencianulasielgruponoexiste.
Sielgruponoexiste,secrea.Siexisteperoestvaco,simplementeseinsertael
nuevo miembro (un grupo no se elimina automticamente cuando quedavaco).
Ysiexisteytieneelementos,laoperacinfallaydevuelvefalse.
La operacin joinGroup no precisa de transacciones: un componente replicado
admite accesos concurrentes sin problemas de consistencia, siempre que la
semnticadelaoperacinlopermita.Sidosrplicasinsertansimultneamentedos
elementos en una lista, la semntica de esta operacin implica que lalistatermina
con dos elementos. Pero si esta operacin serealizasobreundiccionario,ylasdos
rplicasempleanlamismaclave,unodelosvaloressepierde.
De esta manera, la operacin ms lenta, join, no bloquea a las rplicas. Esta
operacinobtienelainformacindelgrupoy,sisteexiste,solicitaunmiembrodel
grupo. Este miembro se emplea, a continuacin, para incluir al nuevo miembro en
su grupo. Si la operacin tiene xito, el nuevo miembro pasa a formar partedeese
grupo:
SenseiGMNS 224
SetMemberInfogroup=map.get(groupName);
if(group==null){
ret=false;
}
else{
MemberInfotoJoin=group.get();
if(toJoin==null){
ret=false;
}
else{
ret=utilJoinGroup(toJoin.handler);
}
}
Este cdigo slo muestra la lgica principal, puesto que el proceso de
inclusindeunmiembroenungrupopuedefallarporproblemasdecomunicaciones
y el servidor GMNS debe entonces repetir el proceso, o devolver un error vlido al
cliente.
TampocoseexplicanenestecaptulootrosalgoritmosdeSenseiGMNS,porser
irrelevantesencuantoasuaplicacindelametodologa,incluyendo:
MtodosparaqueelmismoservidorSenseiGMNSformeungrupoporsmismo,
publicando su informacin en puertos TCP especficos o en direcciones
configurables.
Controldereferenciasinvlidas,pertenecientesamiembrosexcluidosdegrupos.
SlounodelosservidoresGMNSrealizaestecontrol,puesnotienesentidoque
todaslasrplicasverifiquenlasmismasreferencias.
Persistencia de la informacin, de tal manera que si todos los servidores GMNS
secaen,nosepierdanlosdatosdelosgruposexistentesysusmiembros.
Interfaz grfica, que muestra los eventos producidos por los componentes
medianteelpatrndeobservacin.
11.4.Conclusiones
SenseiGMNS completa la funcionalidad del modelo de sincrona virtual no
presente en SenseiGMS, permitiendo la creacin y extensin de grupos. Tambin
presenta funcionalidad extendida para soportar la gestin de grupos mediante
nombres.
La implementacin es un ejemplo de empleo de la metodologa soportada por
SenseiDomains. La aplicacin de esta metodologa pretende facilitar el diseo de
servidores replicados mediante el empleo de componentes, permitiendo que el
SenseiGMNS 225
diseadorseenfoqueenlalgicadelaaplicacinynoenlosmtodosdeaplicaresa
lgica.
Sinembargo,almostrarcmosehadiseadoSenseiGMNS,laimplementacin
de su lgica de aplicacin no ha sido inmediatamente posible. Primero, ha sido
necesario desarrollar los componentes que la sustentan, tarea que conlleva un
considerable esfuerzo. No obstante, debe tenerse en cuenta que, con el soporte de
SenseiUMA,esoscomponenteshabranestadoyadisponibles.
Pero incluso con el empleo de componentes replicados ya disponibles, es
preciso que la aplicacin realice una serie de pasos que permitan su posterioruso,
tales como crear un dominio, registrar los componentes estticos e instruir al
dominio sobre cmo actuar con componentes dinmicos. Una vez concluidos estos
pasos, es posible dedicarse a la lgica de la aplicacin, empleando componentes
replicadoscomosifuerannormales,aunquecompartidosportodaslasrplicas.
Elesfuerzoadicionalparamanejareldominioes,sinembargo,muyinferioral
necesario para programar una aplicacin tolerante a fallos sin soporte de
componentes. Procesos como la optimizacin que hemos realizado en el algoritmo
para bloquear rplicas el mnimo tiempo posible son evidentemente factibles sin el
empleo de componentes, diseando, posiblemente, una lgica de aplicacin muy
diferente, pero la ventaja de esta aproximacin es su semejanza a un caso no
replicado y, consecuentemente, la posibilidad de emplear los mismos algoritmos.
Estalgicaimplica,adems,unamenorcurvadeaprendizaje,loqueresultaenuna
implementacin ms rpida para analistas no experimentados en aplicaciones
tolerantes afallos,ascomoenunamsfcilmigracindeservidoresnoreplicados
asuequivalentereplicado.
SenseiGMNS 226
Conclusionesfinales 227
Captulo12-CONCLUSIONESFINALES
Este ltimo captulo recoge las principales conclusiones de la memoria,
describiendo las aportaciones realizadas y las que consideramos que son nuestras
prximaslneasdeinvestigacinytrabajofuturo.
12.1.Aportacionesrealizadas
El dominio del trabajo que esta memoria presenta son las tcnicas de
desarrollodeaplicacionestolerantesafallosmediantelareplicacindesusrecursos.
En el ncleo de estas tcnicas est el modelo de sincrona virtual, con el cual es
posible programar aplicaciones en grupo bajo la abstraccin de que no hay errores
de comunicaciones entre los miembros del grupo y que todos losmiembrosvenlos
mismoseventosenelmismoorden.
Estemodeloprecisadeunsistemadecomunicacionesfiablesengrupo,ydebe
soportar un conjunto de propiedades y facilidades, como es el servicio de
pertenenciaagrupo,queposibilitaelempleodegruposdinmicos.Enespecial,debe
soportar la transferencia de estado a los miembros que se incluyen en el grupo,de
talformaquetodaslasrplicasmantenganunestadoconsistente;sinembargo,esta
facilidad est dbilmente especificada y su soporte en los sistemas actuales de
comunicacionesfiablesengruposueleserinsuficienteo,incluso,inexistente.
El desarrollo de las aplicaciones replicadas se facilita enormemente con el
modelodesincronavirtual,peroimplicaundiseodebajonivelbasadoenelenvo
de mensajes entre rplicas. Aunque es posible enmascarar la interfaz ofrecida con
orientacin a objetos, la lgica de la replicacin sigue basada en un envo de
mensajes.stoimplicadiseosmuyligadosacadaprograma,dificultandoelempleo
detcnicascomolareutilizacindecomponentes.
La especificacin del servicio CORBA de tolerancia a fallos soluciona todos
estosproblemas,peroimponeunmodelomuyrestrictivo,tantoparalatransferencia
deestado,comoparalasaplicacionesqueloemplean,detalformaqueresultapoco
prctico y efectivo. Sin embargo, debe destacarse que este servicio soporta tanto
replicacin activa como pasiva, pero ambas con el mismo modeloyconunespecial
nfasis sobre la pasiva, lo que puede explicar su poca idoneidad para replicacin
activa.
En este escenario, Sensei analiza, por un lado, la transferencia de estado,
aportando soluciones para aplicaciones no particionables, esto es, aplicaciones en
grupo que, en caso de sufrir problemas de comunicaciones que la dividan en
subgrupos, permiten que slo uno de los subgrupos, en el mejor de los casos,
permanezca operativo. Por otro lado, se centra en la metodologa necesaria para
factorizar una aplicacin tolerante a fallos en componentes replicables, facilitando,
tanto la reutilizacin de esos componentes, como el proceso de su replicacin. El
resultado que se persigue es laequiparacindelasaplicacionesreplicadasconsus
homlogas sin soporte de replicacin, lo que permite un diseo considerablemente
simplificado.
Lasaportacionesqueestamemoriarealizasedividenentresgrupos.Elprimer
gruposecentraenlainvestigacinsobrelatransferenciadeestado:
Consideramos la transferencia de estado como un proceso sobre el modelo de
sincrona virtual, lo que permite implantar las soluciones obtenidas sobre
cualquier sistema de comunicaciones en grupo. Analizamos, entonces, las
condiciones que deben verificar un grupo y sus mensajes para permitir
transferenciasdeestadosimples,siendosimplesaquellasquepuedenefectuarse
conelflujonormaldemensajes,sinprecisarbloqueosotratamientosespeciales.
El resultado es que nicamente las aplicaciones muy sencillas soportan estas
transferencias.
Desarrollamos algoritmos genricos que posibilitan la transferencia basada en
mensajes para todo tipo de aplicaciones. Estos algoritmos soportan
transferencias realizadas en varios pasos y se basan en el bloqueo de los
mensajesdelgrupomientrashayaunatransferenciaencurso.
Estudiamoslassolucionesobtenidasenelmarcodelmodelodesincronavirtual.
La primera conclusin es que este modelo debe extenderse para comunicar los
eventos de bloqueo de vistas; en caso contrario no es posible el bloqueo de
mensajes,loqueimposibilitaelprocesodetransferencia.Lasegundaconclusin
es que toda transferencia debe cancelarse y reiniciarse en caso de cambios de
vistas. Debido al impacto negativo que esta reiniciacin puede tener en el
rendimiento de un grupo, proponemos soluciones alternativas, describiendo su
impactoenelmodelodesincronavirtual.
Diseamosprotocolosdealtoybajonivel(interfazdeaplicacineintercambiode
mensajes) que posibilitan una transferencia de estado cuya principal
caracterstica es la flexibilidad. Admiten transferencias secuenciales, de tipo
pushopull,delegacinenlaeleccindelcoordinadorsobrelaaplicacin,empleo
de propiedades de miembros, transferencias concurrentes e interrupciones y
reanudaciones de las mismas, al soportar un canal de comunicacin
bidireccionalentrelosmiembrosqueparticipanenlatransferencia.
Analizamos los diferentes protocolos de bajo nivel, estudiando los beneficios de
unos u otros segn el tipo de aplicacin, topologa de la red, frecuencia de
errores, etc. La conclusin bsicaesqueelprotocolopushresultamseficiente
salvo que el grupo disponga desoportehardwaredemensajeramultipunto.Es,
porotraparte,mscomplejo,porloqueresultamsdifcildeimplementar.
Especificamos la interfaz de aplicacin de estos protocolos en JavaRMI y
OMG/IDL.Adems,integramosestainterfazconelservicioCORBAdetolerancia
afallos,extendiendosufuncionalidad.
La segunda lnea de investigacin con el sistema desarrollado, Sensei, la
constituyeelestudiodetcnicasdediseodeaplicacionestolerantesafallos:
Analizamos los patrones de implementacin, proponiendo solucionesespecficas
paraelproblemadesincronizacindemensajes.
Estudiamos el proceso de replicacin de una aplicacin con dos resultados.
Primero, describimos el proceso de cmo automatizar la replicacin de una
aplicacin. Esta automatizacin se realiza a partir de la descripcin de su
interfaz y de una implementacin sin soporte de replicacin de esta interfaz.
Segundo, comprobamos la dificultad de automatizar la replicacin de una
aplicacin compleja y la necesidad de factorizarla en componentes, cuya
replicacinyasesautomatizable.
Desarrollamosunametodologabasadaencomponentes.Laprincipalmotivacin
esladelegacindelalgicadereplicacinsobreesoscomponentes,permitiendo
queeldiseodeunaaplicacintoleranteafallospuedacentrarseenlalgicade
esaaplicacin.
Estudiamoselciclodevidadeloscomponentesreplicados,conlapretensinde
equipararlos a los componentes normales, no replicados. El resultado es la
necesidad de permitir componentes replicados dinmicos: no existen desde el
principio, son creados dinmicamente en una mquina y su existencia es
propagada a las dems rplicas. Describimos las posibilidades de
implementacin,centrndonosenelempleodedominios,quepermitengestionar
conjuntamenteloscomponentesreplicadosdeunaaplicacin,
Estudiamos los problemas de concurrencia sobre los componentes replicados,
proponiendo una solucin basada en monitores, cuya interfaz e implementacin
detallamos.Proponemoselempleodetransaccionescomolaformadeasegurarla
consistenciadelgrupoencasodeproblemasalactualizarvarioscomponentesen
unmiembro,ydescribimossuimplementacinenbasealempleodedominios.
Analizamos los impactos de las soluciones propuestas sobre el modelo de
sincrona virtual. Elempleodetransaccionesnoescompatibleconestemodelo,
por lo que analizamos las consecuencias de esa incompatibilidad, describiendo
lasaplicacionesque,porlotanto,nopuedenemplearlas.
Identificamos los contenedores (de datos/objetos) como las estructuras
replicables genricas de una aplicacin, y proponemos el diseo de una librera
bsica de contenedores replicados con el objetivo de facilitar su reutilizacin.
EstalibreraconstituyelapartedeesteproyectodenominadaSenseiUMA.
El resultado que ofrece esta metodologa es la utilizacin efectiva de
componentes, dinmicos o estticos, que simplifica el desarrollo de aplicaciones
tolerantes a fallos. Sin embargo, la transparencia no es total, y debe an incluirse
cierta lgica de replicacin. La situacin es, en cierto modo, comparable a ladelas
aplicaciones distribuidas CORBA: con estas aplicaciones, la abstraccin que se
buscaesladeunainteraccinlocaldecomponentes,auncuandoesoscomponentes
sonremotosylatransparenciadeaccesonoresultatotal,loquesuponeuntrabajo
inicial para localizar esos componentes y una problemtica posterior mayor en su
acceso, por los posibles problemas de comunicaciones. A pesar de esta falta de
transparencia total, consideramos que la metodologa desarrollada facilita
extraordinariamente el diseo e implementacin de las aplicaciones tolerantes a
fallos.
La tercera aportacin que Sensei realiza es un soporte completo de las dos
lneas de investigacin mencionadas, permitiendo comprobar su validez terica con
la prctica (la figura 12.1 muestra los distintos componentes de Sensei y sus
interacciones):
Implementamos un sistema de comunicaciones fiables en grupo. Este sistema,
SenseiGMS, implementasobreCORBAyJavaRMIelmodelodesincronavirtual
con una interfaz orientada aobjetos.Sufuncionalidadselimitaaladefinidaen
este modelo de tal forma que pudiera ser fcilmente reemplazable por otros
sistemas ms eficientes. Hemos diseado tambin el algoritmo de paso de
testigo que emplea SenseiGMS, soportando exclusivamente mensajes con orden
total.
Desarrollamos VirtualNet, una herramienta que permite probar la correccin de
SenseiGMS, as como la de las aplicaciones tolerantes a fallos que lo empleen.
Soporta el desarrollo de topologas virtuales y permite comprobar lareaccinde
lasaplicacionesalosproblemasdecomunicaciones.
Implementamoslametodologadesarrolladapreviamente,ascomolosprotocolos
de trasferencia de estado. Esta implementacin, SenseiDomains, soporta
aplicacionesCORBAyJavaRMI,aligualqueSenseiGMS,queeselsubstratode
comunicaciones que emplea. Una de las principales caractersticas de este
sistema es que, si bien soporta toda la funcionalidad de la metodologa, las
aplicacionessloobservanlaquenecesitan,redundandoenunamejoreficiencia
yunaimplementacindelaaplicacinmssimple.
Finalmente, hemos desarrollado SenseiGMNS, un servicio de directorio para
SenseiGMS. Sin embargo, la principal aportacin de SenseiGMNS es que su
diseo es un ejemplo de aplicacin de la metodologa desarrollada y de
SenseiDomainsporextensin.
12.2.Trabajofuturo
Nuestro trabajo futuro sobre Sensei tiene dos vertientes: consolidacin del
trabajorealizadoyevolucinconnuevaspropuestas.
Dentrodelaconsolidacin,tenemospendientelasubstitucindelsubstratode
comunicaciones empleado, SenseiGMS, por otros sistemas de comunicaciones en
grupo. El esfuerzo asociado no se realizara para incrementar la eficiencia del
sistema, sino para verificar la correccin de la implementacin de la metodologa.
Aunque SenseiDomains emplea nicamente la interfaz pblica de SenseiGMS, slo
laprcticapermitircomprobarlasdeduccioneserrneasquehayamospodidohacer
Figura12.1.ComponentesdeSensei
SenseiGMS
sistemadecomunicacionesfiablesengrupo
metodologa dedesarrollo
SenseiDomains
SenseiGMNS
servicio dedirectorio
servicio
bsico de
gestinde
grupos
Aplicacintoleranteafallos
Modelo
de
sincrona
virtual
Interacciones
debajonivel
sobre el comportamientodelmodelodesincronavirtual.Hastaelmomento,hemos
podidoyaencapsularEnsemblebajolainterfazdeSenseiGMS,aunquelimitadosala
implementacin CORBA. Adems, como inicialmente la interfaz de SenseiGMS se
dise bajo la influencia de Ensemble, puede resultar ms interesante realizar la
substitucinconotrosistemadiferente,comoTransis.
Para consolidar la metodologa desarrollada debemos, tambin, validarla con
un nmero suficiente de aplicaciones, preferiblemente implementadas fuera de
nuestro grupo de trabajo, para obtener as respuestas independientes. Un aspecto
que ya consideramos mejorable en la metodologa es su tratamiento de la
transferenciadeestadoconrespectoamltiplescomponentes.Transferirprimeroel
estadodeloscomponentesmsantiguosofreceunresultadovlido,peroineficiente;
la transferencia simultnea de estados de varios componentes puede, obviamente,
provocar errores de consistencia, salvo que la aplicacin pueda anticiparlos y
obtenerasunaeficienciamayor.
Consideramos tambin un problema de consolidacin el empleo de los
monitoresreplicados.Suinterfaznodefineoperacionesdeguarda(wait,notify),cuya
implementacin no precisa, sin embargo, de un gran esfuerzo. No obstante, su
objetivo en la metodologa es la definicin de regiones crticas, permitiendo la
sincronizacindeaccesoarecursos.Lasoperacionesdeguardaseusan,enelcaso
de aplicaciones multithread, para la colaboracin entre mltiples threads, mientras
quelametodologadesarrolladanoprevlacolaboracinentrecomponentes.
La principal lnea de investigacin actual es SenseiUMA, el diseo de una
librera de componentes estndar replicados. Este diseo lo realizamos basndonos
en los contenedores existentes en Java (java.util), pero su contenido no est an
completado.Tambinhemosdebidopostergarsuimplementacin,puesbajoCORBA
es slo posible perdiendo gran parte de la transparencia, ya que la aplicacin debe
poder especificar cmotransferirelestadodecadaelementoenelcontenedor.Esta
implementacinsqueestsiendoposibleconJavaRMI,perodebemosinvestigarlas
mejorasquehacenespecialmenteinteresanteelempleoefectivodeloscomponentes.
Finalmente, el trabajo desarrollado considera grupos no particionables, por lo
que se podra considerar la principal evolucin de Sensei su aplicabilidad sobre
aplicacionestolerantesafallosquepermitanparticiones.Estalneadeinvestigacin
es, sin embargo, sumamente complicada. Los algoritmos de transferencia de estado
desarrolladossonexclusivosparasistemasnoparticionablesylomismoocurrecon
lametodologa.Debedestacarsequeensistemasqueadmitenvariosgruposactivos,
esprecisalaintervencindelaaplicacinparadecidircmomezclarcoherentemente
susestadoscuandoserenandenuevoesosgrupos,yestaintervencinimplicaun
usonotransparentedeloscomponentes.Sinembargo,estemezcladodeestadoses,
de hecho, ms sencillo cuando se emplean componentes bsicos. Por ejemplo, un
componente replicado lista que se divide en dos grupos, peromantieneunhistorial
de sus cambios, puede luego realizar, en muchos casos, un mezclado coherente de
losdatosenbaseaesoscambios.
En cualquier caso, esta lnea de investigacin supone un cambio de criterio
completo con respecto al trabajo desarrollado hasta el momento, que busca una
simplificacin del proceso de replicacin, haciendo que su lgica resulte lo ms
transparente posible para la aplicacin. Una aplicacin que soporte particionado
debe imbuir desde un principio toda la lgica necesaria para soportar estados
inconsistentes, perdiendo, consecuentemente, inters en esa transparencia. Por lo
tanto, consideramos actualmente queelsoportedeaplicacionesparticionadasenla
metodologatieneunintersmeramenteterico.
EspecificacinCORBAdeSenseiGMS 235
ApndiceA.ESPECIFICACINCORBA
DESENSEIGMS
A.1.GroupMembershipService.idl
#ifndefVIRTUAL_SYNCHRONY_IDL
#defineVIRTUAL_SYNCHRONY_IDL
modulesensei
{
modulemiddleware
{
moduleGMS
{
typedeflongGroupMemberId;
constGroupMemberIdINVALID_GROUP_MEMBER_ID=0;
structView
{
longviewId;
GroupMemberIdListmembers;
GroupMemberIdListexpulsedMembers;
};
valuetypeMessage
{
};
interfaceGroupHandler
{
GroupMemberIdgetGroupMemberId();
booleanisValidGroup();
booleanleaveGroup();
booleancastMessage(inMessagemsg);
booleansendMessage(inGroupMemberIdtarget,inMessagemsg);
};
interfaceGroupMember
{
voidprocessPTPMessage(inGroupMemberIdsender,inMessagemsg);
voidprocessCastMessage(inGroupMemberIdsender,inMessagemsg);
voidmemberAccepted(inGroupMemberIdidentity,inGroupHandlerhandler,
inViewtheView);
voidchangingView();
voidinstallView(inViewtheView);
voidexcludedFromGroup();
};
};
};
};
#endifVIRTUAL_SYNCHRONY_IDL
A.2.InternalSensei.idl
#ifndefINTERNAL_SENSEI_IDL
#defineINTERNAL_SENSEI_IDL
#include"GroupMembershipService.idl"
modulesensei
{
modulemiddleware
{
moduleGMS
{
interfaceSenseiGMSMember;
structToken
{
GroupMemberIdcreator;
longid;
};
structInternalViewId
{
longid;
longinstalling;
};
typedefsequence<SenseiGMSMember>SenseiGMSMemberList;
structInternalView
{
InternalViewIdviewId;
SenseiGMSMemberListmembers;
GroupMemberIdListmemberIds;
};
structMessageId
{
longview;
longid;
};
typedefsequence<Message>MessageList;
structAllowTokenRecoveryAnswer
{
booleanvalidCommunication;
booleanrecoveryAllowed;
MessageIdlastMessage;
};
{
booleanreceiveToken(inGroupMemberIdsender,inTokentheToken);
booleanreceiveView(inGroupMemberIdsender,inInternalViewview,
inTokenviewToken);
booleanreceiveMessages(inGroupMemberIdsender,inMessageListmessages,
inMessageIdmsgId);
booleanconfirmMessages(inGroupMemberIdsender,inMessageIdmsgId);
booleanreceivePTPMessages(inGroupMemberIdsender,inMessageListmessages,
inMessageIdmsgId);
AllowTokenRecoveryAnswerallowTokenRecovery(inGroupMemberIdsender,
inInternalViewIdmyViewId);
booleanrecoverToken(inGroupMemberIdsender);
};
};
};
};
#endifINTERNAL_SENSEI_IDL
EspecificacinCORBAdeSenseiDomains 239
ApndiceB.ESPECIFICACINCORBA
DESENSEIDOMAINS
B.1.DomainExceptions.idl
#ifndefDOMAIN_EXCEPIONS_IDL
#defineDOMAIN_EXCEPIONS_IDL
modulesensei
{
modulemiddleware
{
moduledomains
{
enumMemberStateExceptionReason
{
MemberNotJoined,
MemberJoined,
MemberWithoutState,
MemberExcluded
};
exceptionMemberStateException
{
MemberStateExceptionReasonreason;
};
};
};
};
#endifDOMAIN_EXCEPIONS_IDL
B.2.StateTransfer.idl
#ifndefSTATE_TRANSFER_IDL
#defineSTATE_TRANSFER_IDL
modulesensei
{
modulemiddleware
{
moduledomains
{
typedefsensei::middleware::GMS::GroupMemberGroupMember;
typedefsensei::middleware::GMS::GroupMemberIdGroupMemberId;
abstractvaluetypeState{};
typedefGroupMemberIdLocation;
typedefsequence<Location>Locations;
interfaceCheckpointable:GroupMember
{
StategetState();
voidsetState(inStates);
};
typedefstringName;
typedefstringValue;
structProperty
{
Namenam;
Valueval;
};
valuetypePhaseCoordination
{
publicbooleantransferFinished;
};
interfaceExtendedCheckpointable:Checkpointable
{
voidassumeState();
};
interfaceBasicStateHandler:GroupMember
{
voidassumeState();
voidstartTransfer(inLocationsjoiningMembers,
StategetState(inoutPhaseCoordinationphase);
voidsetState(inStates,inPhaseCoordinationphase);
voidstopTransfer(inLocationsjoiningMembers,inbooleantransferFinished);
};
interfaceStateHandler:BasicStateHandler
{
voidsyncTransfer(inLocationcoordinator,inoutPhaseCoordinationphase);
voidinterruptTransfer(inoutPhaseCoordinationphase);
voidcontinueTransfer(inLocationsjoiningMembers,
inoutPhaseCoordinationcoordinator,
inPhaseCoordinationjoining);
};
structCoordinatorInformation
{
LocationstatusMember;
LocationscurrentCoordinations;
};
typedefsequence<CoordinatorInformation>CoordinatorInformationList;
interfaceCoordinatorElector
{
LocationgetCoordinator(inLocationloc,inCoordinatorInformationListinfo);
};
enumBehaviourOnViewChanges
{
MembersOnTransferExcludedFromGroup,
StatelessMembersDoNotBelongToGroup,
StatelessMembersBelongToGroup
};
};
};
};
#endifSTATE_TRANSFER_IDL
B.3.Properties.idl
#ifndefPROPERTIES_IDL
#definePROPERTIES_IDL
#include"DomainExceptions.idl"
#include"StateTransfer.idl"
modulesensei
{
modulemiddleware
{
moduledomains
{
structMemberProperties
{
GroupMemberIdmember;
Propertiesprops;
};
exceptionPropertiesDisabledException
{
};
interfacePropertiesListener
{
voidpropertiesUpdated(inLocationloc);
};
interfacePropertiesHandler
{
voidenableProperties()raises(MemberStateException);
booleanarePropertiesEnabled();
voidsetPropertiesListener(inPropertiesListenerlistener)
raises(PropertiesDisabledException);
MemberPropertiesListgetAllProperties()
MemberPropertiesListgetPropertyForAllMembers(inNamenam)
PropertiesgetMemberProperties(inLocationloc)
ValuegetMemberProperty(inLocationloc,inNamen)
PropertiesgetProperties()raises(PropertiesDisabledException);
ValuegetProperty(inNamen)raises(PropertiesDisabledException);
voidsetProperties(inPropertiesprops)
voidaddProperties(inPropertiesprops)
voidremoveProperties(inPropertiesprops)
};
};
};
};
#endifPROPERTIES_IDL
B.4.SubgroupsHandler.idl
#ifndefSUBGROUPS_HANDLER_IDL
#defineSUBGROUPS_HANDLER_IDL
modulesensei
{
modulemiddleware
{
moduledomains
{
typedeflongSubgroupId;
typedefsequence<SubgroupId>SubgroupIdsList;
constlongEVERY_SUBGROUP=0;
constlongMAX_STATIC_SUBGROUP_ID=65535;
enumSubgroupsHandlerExceptionReason
{
SubgroupIdAlreadyInUse,
InvalidStaticSubgroupId,
InvalidDynamicSubgroupId,
DynamicBehaviourNotRegistered
};
exceptionSubgroupsHandlerException
{
SubgroupsHandlerExceptionReasonreason;
};
valuetypeDynamicSubgroupInfo
{
};
valuetypeDynamicSubgroupInfoAsString:DynamicSubgroupInfo
{
publicstringinfo;
};
interfaceDynamicSubgroupsUser
{
GroupMemberacceptSubgroup(inSubgroupIdid,inDynamicSubgroupInfoinfo);
GroupMembersubgroupCreated(inGroupMemberIdcreator,inSubgroupIdid,
voidsubgroupRemoved(inGroupMemberIdremover,inSubgroupIdid,
};
interfaceSubgroupsHandler
{
voidsetDynamicSubgroupsUser(inDynamicSubgroupsUseruser)
voidregisterSubgroup(inSubgroupIduniqueSubgroupId,inGroupMembersubgroup)
voidcastSubgroupCreation(inDynamicSubgroupInfoinfo)
SubgroupIdcreateSubgroup(inDynamicSubgroupInfoinfo,
inGroupMembersubgroup)
booleanremoveSubgroup(inSubgroupIdid,inDynamicSubgroupInfoinfo)
SubgroupIdsListgetSubgroups();
GroupMembergetSubgroup(inSubgroupIdid);
SubgroupIdgetSubgroupId(inGroupMembersubgroup);
};
};
};
};
#endifSUBGROUPS_HANDLER_IDL
B.5.DomainMessage.idl
#ifndefDOMAIN_MESSAGE_IDL
#defineDOMAIN_MESSAGE_IDL
#include"SubgroupsHandler.idl"
modulesensei
{
modulemiddleware
{
moduledomains
{
typedefsensei::middleware::GMS::MessageMessage;
typedeflongMessageId;
valuetypeDomainMessage:Message
{
publicSubgroupIdsubgroup;
publicbooleanunqueuedOnST;
publicbooleanunTransactionable;
publicbooleanwaitReception;
publicMessageIdid;
};
};
};
};
#endifDOMAIN_MESSAGE_IDL
B.6.Concurrency.idl
#ifndefCONCURRENCY_IDL
#defineCONCURRENCY_IDL
#include"DomainMessage.idl"
modulesensei
{
modulemiddleware
{
moduledomains
{
typedefsensei::middleware::GMS::GroupMemberIdListGroupMemberIdList;
exceptionMonitorException{};
interfaceMonitor
{
voidlock()raises(MemberStateException);
voidunlock()raises(MonitorException,MemberStateException);
};
interfaceGroupMonitor:Monitor,ExtendedCheckpointable
{
};
exceptionTransactionException{};
interfaceTransactionsHandler
{
voidstartTransaction(inMonitorlocker)
voidendTransaction()
};
};
};
};
#endifCONCURRENCY_IDL
B.7.DomainGroupHandler.idl
#ifndefDOMAIN_GROUP_HANDLER_IDL
#defineDOMAIN_GROUP_HANDLER_IDL
#include"Concurrency.idl"
#include"Properties.idl"
modulesensei
{
modulemiddleware
{
moduledomains
{
typedefsensei::middleware::GMS::GroupHandlerGroupHandler;
enumDomainExpulsionReason
{
GMSLeaveEvent,
WrongPropertyAllowance,
WrongStaticSubgroupsComposition,
WrongCoordinatorElectionPolicy,
WrongBehaviourMode,
WrongDynamicPolicy,
WrongSubgroupsTypes,
SubgroupError
};
exceptionSyncCastDomainMessageProcessedException
{
};
interfaceDomainGroupUser
{
voiddomainAccepted(inGroupMemberIdid);
voiddomainExpulsed(inDomainExpulsionReasonreason);
voidstateObtained(inbooleanassumed);
voidoffendingSubgroup(inSubgroupIdsubgroup,instringreason);
};
interfaceDomainGroupHandler:GroupHandler,GroupMember,PropertiesHandler,
SubgroupsHandler,TransactionsHandler
{
voidsetBehaviourMode(inBehaviourOnViewChangesmode)
voidsetCoordinatorElector(inCoordinatorElectorelector)
voidsetDomainGroupUser(inDomainGroupUseruser)
GroupMemberIdListgetStatefulMembers()
booleansyncCastDomainMessage(inDomainMessagemessage,
inbooleannormalProcessing)
voidsyncCastDomainMessageProcessed()
raises(MemberStateException,SyncCastDomainMessageProcessedException);
};
};
};
};
#endifDOMAIN_GROUP_HANDLER_IDL
B.8.InternalDomainMessages.idl
#ifndefINTERNAL_DOMAIN_MESSAGES_IDL
#defineINTERNAL_DOMAIN_MESSAGES_IDL
#include"DomainGroupHandler.idl"
modulesensei
{
modulemiddleware
{
moduledomains
{
enumStateTransferType
{
STT_StateHandler,
STT_BasicStateHandler,
STT_ExtendedCheckpointable,
STT_Checkpointable,
STT_StatelessTransfer
};
structSubgroupProperties
{
SubgroupIdid;
DynamicSubgroupInfoinfo;
StateTransferTypetype;
};
typedefsequence<SubgroupProperties>SubgroupsInfo;
structReplicaInformation
{
GroupMemberIdreplicaId;
GroupMemberIdListreplicasToCoordinate;
};
typedefsequence<ReplicaInformation>ReplicasInformation;
valuetypeMessageP:DomainMessage
{
publiclongviewId;
publicBehaviourOnViewChangesbehaviour;
publicbooleancoordinatorElectorRegistered;
publicbooleandynamicSubgroupsAllowed;
publiclongnextDynamicSubgroupId;
publicSubgroupsInfosubgroupsInformation;
publicMemberPropertiesListprops;
publicReplicasInformationreplicasInfo;
};
structSubgroupCoordination
{
SubgroupIdid;
PhaseCoordinationphase;
};
typedefsequence<SubgroupCoordination>SubgroupCoordinations;
valuetypeMessageC:DomainMessage
{
publiclongviewId;
publicSubgroupCoordinationscoordinations;
publicbooleancontainOwnProperties;
publicPropertiesprops;
};
valuetypeMessageE:DomainMessage
{
publiclongviewId;
publicGroupMemberIdmember;
};
structSubgroupState
{
SubgroupIdid;
PhaseCoordinationphase;
StatesubState;
};
typedefsequence<SubgroupState>SubgroupStates;
valuetypeMessageS:DomainMessage
{
publiclongviewId;
publicSubgroupStatesstates;
};
valuetypeMessageMemberProperties:DomainMessage
{
};
valuetypeMessageCreateSubgroup:DomainMessage
{
publicDynamicSubgroupInfoinfo;
publiclongcreatorId;
};
valuetypeMessageRemoveSubgroup:DomainMessage
{
publicSubgroupIdsubgroupToRemove;
publicDynamicSubgroupInfoinfo;
};
valuetypeMonitorMessage:DomainMessage
{
publicbooleanlock;
};
valuetypeEndOfTransactionMessage:DomainMessage
{
publicsequence<Message>actions;
};
valuetypeMonitorState:State
{
publicGroupMemberIdListlocks;
};
};
};
};
#endifINTERNAL_DOMAIN_MESSAGES_IDL
EspecificacinCORBAdeSenseiGMNS 251
ApndiceC.ESPECIFICACINCORBA
DESENSEIGMNS
C.1.GroupMembershipNamingService.idl
#ifndefGROUP_MEMBERSHIP_NAMING_SERVICE
#defineGROUP_MEMBERSHIP_NAMING_SERVICE
modulesensei
{
modulemiddleware
{
moduleGMNS
{
typedefsensei::middleware::GMS::GroupHandler GroupHandler;
typedefsensei::middleware::GMS::GroupMember GroupMember;
exceptionInvalidGroupHandlerException{};
exceptionInvalidGroupHandlerFactoryException{};
exceptionGroupHandlerFactoryException{};
interfaceGroupHandlerFactory
{
GroupHandlercreate()raises(GroupHandlerFactoryException);
};
valuetypeGroupHandlerFactoryCreator
{
GroupHandlerFactorycreate(inGroupMembermember)
raises(GroupHandlerFactoryException);
};
interfaceGroupMembershipBasicService
{
GroupHandlercreateGroup(inGroupHandlerFactorytheFactory)
raises(InvalidGroupHandlerFactoryException,
GroupHandlerjoinGroup(inGroupHandlergroup,
inGroupHandlerFactorytheFactory)
raises(InvalidGroupHandlerException,
};
interfaceReplicatedServer
{
};
typedefsequence<ReplicatedServer>ReplicatedServersList;
interfaceGroupMembershipNamingService
{
GroupHandlerfindAndJoinGroup(instringgroupName,
inGroupHandlerFactorytheFactory,
instringmemberName,
inReplicatedServerclientsReference)
raises(sensei::middleware::domains::MemberStateException,
voidleaveGroup(instringgroupName,inGroupHandlermember);
ReplicatedServersListgetGroup(instringgroupName)
ReplicatedServergetGroupServer(instringgroupName,instringmemberName)
ReplicatedServergetValidGroupServer(instringgroupName)
};
};
};
};
#endifGROUP_MEMBERSHIP_NAMING_SERVICE
C.2.MemberInfo.idl
#ifndefMEMBER_INFO
#defineMEMBER_INFO
#include"GroupMembershipNamingService.idl"
modulesensei
{
modulemiddleware
{
moduleGMNS
{
structMemberInfo
{
stringname;
ReplicatedServerpublicReference;
};
typedefsequence<MemberInfo>MemberInfoList;
};
};
};
#endifMEMBER_INFO
C.3.SetMemberInfo.idl
#ifndefSET_MEMBER_INFO
#defineSET_MEMBER_INFO
#include"DomainGroupHandler.idl"
#include"MemberInfo.idl"
modulesensei
{
modulemiddleware
{
moduleGMNS
{
typedefsensei::middleware::domains::DomainMessageDomainMessage;
typedefsensei::middleware::domains::ExtendedCheckpointable
ExtendedCheckpointable;
typedefsensei::middleware::domains::StateState;
interfaceSetMemberInfoObservable;
interfaceSetMemberInfoObserver
{
voidaddDone(inSetMemberInfoObservableobservable,inMemberInfomember);
voidremoveDone(inSetMemberInfoObservableobservable,inMemberInfomember);
};
interfaceSetMemberInfoObservable
{
voidaddObserver(inSetMemberInfoObserverobserver);
booleanremoveObserver(inSetMemberInfoObserverobserver);
};
interfaceSetMemberInfo:ExtendedCheckpointable,SetMemberInfoObservable
{
booleanadd(inMemberInfomember)
booleanremove(inMemberInfohandler)
MemberInfoget()
MemberInfoListtoArray()
};
valuetypeSetMemberInfoChangedMessage:DomainMessage
{
publicMemberInfoinfo;
publicbooleanadd;
};
valuetypeSetMemberInfoState:State
{
publicsequence<MemberInfo>members;
};
};
};
};
#endifSET_GROUP_HANDLER
C.4.MapStringSet.idl
#ifndefMAP_STRING_SET
#defineMAP_STRING_SET
#include"SetMemberInfo.idl"
modulesensei
{
modulemiddleware
{
moduleGMNS
{
typedefsensei::middleware::domains::SubgroupIdSubgroupId;
exceptionInvalidSetMemberInfo{};
interfaceMapStringSetObservable;
interfaceMapStringSetObserver
{
voidclearDone(inMapStringSetObservableobservable);
voidputDone(inMapStringSetObservableobservable,instringgroupName,
voidremoveDone(inMapStringSetObservableobservable,instringgroupName,
};
interfaceMapStringSetObservable
{
voidaddObserver(inMapStringSetObserverobserver);
booleanremoveObserver(inMapStringSetObserverobserver);
};
typedefsequence<string>stringList;
interfaceMapStringSet:ExtendedCheckpointable,MapStringSetObservable
{
SetMemberInfoput(instringgroupName,inSetMemberInfoset)
raises(InvalidSetMemberInfo,
sensei::middleware::domains::MemberStateException);
SetMemberInforemove(instringgroupName)
SetMemberInfoget(instringgroupName)
stringListgetKeys()
};
valuetypeMapStringSetPutMessage:DomainMessage
{
publicstringkey;
publicSubgroupIdvalue;
};
valuetypeMapStringSetRemoveMessage:DomainMessage
{
publicstringkey;
};
structMapStringSetEntry
{
stringkey;
SubgroupIdvalue;
};
valuetypeMapStringSetState:State
{
publicsequence<MapStringSetEntry>groups;
};
};
};
};
#endifMAP_STRING_SET
C.5.GroupsCheckerState.idl
#ifndefGROUPS_CHECKER_STATE
#defineGROUPS_CHECKER_STATE
modulesensei
{
modulemiddleware
{
moduleGMNS
{
typedefsensei::middleware::domains::StateState;
typedefsensei::middleware::GMS::GroupMemberIdGroupMemberId;
valuetypeGroupsCheckerState:State
{
publicGroupMemberIdchecker;
};
};
};
};
#endifGROUPS_CHECKER_STATE
EjemplosdeComponentesReplicados 259
ApndiceD.EJEMPLOSDE
COMPONENTESREPLICADOS
Este apndice incluye el cdigo de algunas clases relevantes en SenseiGMNS,
siguiendolaexplicacindelcaptulo11.Estasclasesimplementanloscomponentes
replicadosempleados;enconcreto,SetMemberInfoImpl.javadefineelcomportamiento
del componente SetMemberInfo y MapStringSetImpl.java implementa el componente
MapStringSet.
D.1.SetMemberInfoImpl.java
packagesensei.GMNS;
importsensei.middleware.GMS.*;
importsensei.middleware.GMNS.*;
importsensei.middleware.domains.*;
importsensei.middleware.util.ObjectsHandling;
importsensei.util.Error;
importjava.util.HashSet;
importjava.util.Iterator;
importjava.util.Set;
classSetMemberInfoImplextendsSetMemberInfoBaseImpl
{
privateSetMemberInfoImpl(DomainGroupHandlergroupHandler)throwsException
{
this.groupHandler=groupHandler;
set=newHashSet();
factory=newGMNSFactory(groupHandler);
observersHandler=newSetMemberInfoObserversHandler(thisSetMemberInfo);
}
publicintgetSubgroupId()
{
returnsubgroupId;
}
privatevoidsetSubgroupId(intsubgroupId)
{
this.subgroupId=subgroupId;
factory.setSubgroupId(subgroupId);
}
publicSetMemberInfoImpl(intsubgroupId,DomainGroupHandlergroupHandler)
throwsException
{
this(groupHandler);
setSubgroupId(subgroupId);
}
publicSetMemberInfoImpl(DynamicSubgroupInfodynamicSubgroupInfo,
DomainGroupHandlergroupHandler)
throwsSubgroupsHandlerException,MemberStateException,Exception
{
this(groupHandler);
subgroupId=groupHandler.createSubgroup(dynamicSubgroupInfo,thisSetMemberInfo);
}
publicvoidregister()
throwsMemberStateException,SubgroupsHandlerException,Exception
{
groupHandler.registerSubgroup(subgroupId,thisSetMemberInfo);
}
publicstaticvoidregister(DynamicSubgroupInfodynamicSubgroupInfo,
{
groupHandler.castSubgroupCreation(dynamicSubgroupInfo);
}
voidfreeResources()
{
if(set!=null){
try{deactivate();}catch(Exceptionex){}
set.clear();
set=null;
groupHandler=null;
factory=null;
}
}
publicbooleanadd(MemberInfoinfo)throwsMemberStateException
{
try{
factory.castSetMessage(info,true);
result=addMemberInfo(info);
}
catch(Exceptionex){Error.unhandledException(Consts.AREA,ex);}
returnresult;
}
publicsynchronizedMemberInfoget()throwsMemberStateException
{
returnit.hasNext()?(MemberInfo)it.next():null;
}
publicbooleanremove(MemberInfoinfo)throwsMemberStateException
{
try{
factory.castSetMessage(info,false);
result=removeMemberInfo(info);
}
returnresult;
}
publicsynchronizedMemberInfo[]toArray()
{
intsize=set.size();
MemberInfo[]ret=newMemberInfo[size];
set.toArray(ret);
returnret;
}
publicsynchronizedvoidaddObserver(SetMemberInfoObserverobserver)
{
observersHandler.addObserver(observer,getMembers());
}
publicbooleanremoveObserver(SetMemberInfoObserverobserver)
{
returnobserversHandler.removeObserver(observer);
}
publicsynchronizedStategetState()
{
returnfactory.createSetState(getMembers());
}
MemberInfo[]getMembers()
{
intsize=set.size();
MemberInfomembers[]=newMemberInfo[size];
if(size>0){
inti=0;
while(it.hasNext())
members[i++]=(MemberInfo)it.next();
}
returnmembers;
}
publicsynchronizedvoidsetState(Statestate)
{
set.clear();
MemberInfomembers[]=((SetMemberInfoState)state).members;
intsize=members.length;
for(inti=0;i<size;i++)
addMemberInfo(members[i]);
}
publicsynchronizedvoidassumeState()
{
set.clear();
}
{
memberId=id;
}
{
freeResources();
}
{
if(messageinstanceofSetMemberInfoChangedMessage){
synchronized(this){
SetMemberInfoChangedMessagemsg=(SetMemberInfoChangedMessage)message;
if(msg.add)
addMemberInfo(msg.info);
else
removeMemberInfo(msg.info);
}
}
}
synchronizedbooleanaddMemberInfo(MemberInfomemberInfo)
{
booleanret=set.add(memberInfo);
if(ret)
observersHandler.informPut(memberInfo);
returnret;
}
synchronizedbooleanremoveMemberInfo(MemberInfomemberInfo)
{
MemberInfocontent=(MemberInfo)it.next();
if(ObjectsHandling.areEquivalent(memberInfo.handler,content.handler)){
it.remove();
observersHandler.informRemove(memberInfo);
returntrue;
}
}
returnfalse;
}
Setset;
intsubgroupId,memberId;
DomainGroupHandlergroupHandler;
GMNSFactoryfactory;
SetMemberInfoObserversHandlerobserversHandler;
};
D.2.MapStringSetImpl.java
packagesensei.GMNS;
importsensei.middleware.GMS.*;
importsensei.middleware.GMNS.*;
importsensei.middleware.domains.*;
importsensei.util.Error;
importjava.util.HashMap;
importjava.util.Iterator;
importjava.util.Map;
classMapStringSetImplextendsMapStringSetBaseImpl
{
privateMapStringSetImpl(DomainGroupHandlergroupHandler)throwsException
{
this.groupHandler=groupHandler;
map=newHashMap();
factory=newGMNSFactory(groupHandler);
observersHandler=newMapStringSetObserversHandler(thisMapStringSet);
}
publicintgetSubgroupId()
{
returnsubgroupId;
}
privatevoidsetSubgroupId(intsubgroupId)
{
this.subgroupId=subgroupId;
factory.setSubgroupId(subgroupId);
}
publicMapStringSetImpl(intsubgroupId,DomainGroupHandlergroupHandler)
throwsException
{
this(groupHandler);
}
publicMapStringSetImpl(DynamicSubgroupInfodynamicSubgroupInfo,
throwsSubgroupsHandlerException,MemberStateException,Exception
{
this(groupHandler);
subgroupId=groupHandler.createSubgroup(dynamicSubgroupInfo,thisMapStringSet);
}
publicvoidregister()
{
groupHandler.registerSubgroup(subgroupId,thisMapStringSet);
}
publicstaticvoidregister(DynamicSubgroupInfodynamicSubgroupInfo,
{
groupHandler.castSubgroupCreation(dynamicSubgroupInfo);
}
voidfreeResources()
{
if(map!=null){
try{deactivate();}catch(Exceptionex){}
map.clear();
groupHandler=null;
factory=null;
}
}
publicSetMemberInfoput(Stringgroup,SetMemberInfoset)throws
InvalidSetMemberInfo,MemberStateException
{
try{
intsubgroupId=groupHandler.getSubgroupId(set);
if(subgroupId==Consts.INVALID_SUBGROUP)
thrownewInvalidSetMemberInfo();
factory.castMapPutMessage(group,subgroupId);
result=doPut(group,set);
}
returnresult;
}
publicSetMemberInforemove(Stringgroup)throwsMemberStateException
{
try{
factory.castMapRemoveMessage(group);
result=doRemove(group);
}
returnresult;
}
publicSetMemberInfoget(Stringgroup)
{
try{
ret=(SetMemberInfo)map.get(group);
}
returnret;
}
publicsynchronizedString[]getKeys()
{
Stringret[]=null;
try{
intsize=map.size();
ret=newString[size];
for(Iteratorit=map.keySet().iterator();it.hasNext();)
ret[size]=(String)it.next();
}
returnret;
}
publicvoidaddObserver(MapStringSetObserverobserver)
{
observersHandler.addObserver(observer);
}
publicbooleanremoveObserver(MapStringSetObserverobserver)
{
returnobserversHandler.removeObserver(observer);
}
publicStategetState()
{
intsize=map.size();
MapStringSetEntryentries[]=newMapStringSetEntry[size];
if(size>0){
inti=0;
Iteratorit=map.entrySet().iterator();
Map.Entryentry=(Map.Entry)it.next();
try{
intsubgroup=groupHandler.getSubgroupId((SetMemberInfo)entry.getValue());
entries[i++]=newMapStringSetEntry((String)entry.getKey(),subgroup);
}
}
}
returnfactory.createMapState(entries);
}
publicvoidsetState(Statestate)
{
map.clear();
MapStringSetEntryentries[]=((MapStringSetState)state).groups;
intsize=entries.length;
for(inti=0;i<size;i++){
try{
GroupMembersubgroup=groupHandler.getSubgroup(entries[i].value);
if(subgroup!=null){
doPut(entries[i].key,set);
}
}
}
}
publicvoidassumeState()
{
map.clear();
}
{
memberId=id;
}
{
freeResources();
}
{
try{
if(messageinstanceofMapStringSetPutMessage){
MapStringSetPutMessagemsg=(MapStringSetPutMessage)message;
GroupMembersubgroup=groupHandler.getSubgroup(msg.value);
if(subgroup!=null){
if(set!=null)
doPut(msg.key,set);
}
}
elseif(messageinstanceofMapStringSetRemoveMessage){
doRemove(((MapStringSetRemoveMessage)message).key);
}
}
}
SetMemberInfodoPut(Stringgroup,SetMemberInfoset)
{
Objectobj=null;
synchronized(this){obj=map.put(group,set);}
if(obj!=null){
}
observersHandler.informPut(group,set);
returnret;
}
SetMemberInfodoRemove(Stringgroup)
{
Objectobj=null;
synchronized(this){obj=map.remove(group);}
if(obj!=null){
}
returnret;
}
synchronizedvoiddoClear()
{
map.clear();
observersHandler.informClear();
}
Mapmap;
intsubgroupId,memberId;
DomainGroupHandlergroupHandler;
GMNSFactoryfactory;
MapStringSetObserversHandlerobserversHandler;
};
Glosario 271
GLOSARIO
BOA Basic Object Adapter (adaptador bsico de objetos). Trmino relacionado con
CORBA.
CORBA Common Object Request Broker Architecture, arquitectura distribuida del
OMG.
DCOMDistributedComponentObjectModel,arquitecturadistribuidadeMicrosoft
FIFO First In, First Out (primero que entra, primero que sale). Trmino empleado
parareferirseaunordenespecficoenmensajes.
GMNS Group Membership Naming Service, servicio de gestin de grupos basado en
nombres.
GMP Group Membership Protocol, protocolo del servicio de gestin de grupos.
Trminorelacionadoconelmodelodesincronavirtual.
GMS Group Membership Service, servicio de gestin agrupos,tambintraducidoen
esta memoria por servicio de pertenencia a grupo. Trminorelacionadoconel
modelodesincronavirtual.
HTMLHyperTextMarkupLanguaje,lenguajehipertextobasadoenetiquetas.
HTTP Hipertext Transfer Protocol, protocoloempleadoenlatransferenciadepginas
HTML.
IDLInterfaceDefinitionLanguage(lenguajededefinicindeinterfaz).
Glosario 272
IIOP Internet Inter-ORB Protocol, protocolo para la comunicacin entre ORBs sobre
Internet.TrminorelacionadoconCORBA.
IOGR Interoperable Object Group Reference, referencia de grupos de objetos entre
ORBs.TrminorelacionadoconCORBA.
IPInternetProtocol,protocolodered.
JMSJavaMessagingService(serviciodemensajeraJava).
JSPJavaServerPages,pginasdeservidorJava.
OMGObjectManagementGroup.
ORBObjectRequestBroker,gestordeobjetosremotos.
OSI Open Systems Interconnections, modelo abierto de interconexin de sistemas.
Trminorelacionadoconsistemasdistribuidos.
POA Portable Object Adapter, adaptador de objetos portable, en cuanto a su
independenciadelORB.TrminorelacionadoconCORBA.
RMI Remot Method Invocation (invocacin remota de mtodos). Es el gestor de
objetosdistribuidosenJava.
RPCRemotProcedureCall(llamadasaprocedimientosremotos).
SOAPSimpleObjectAccessProtocol.Protocolosimpledeaccesoaobjetos.
STL Standar Template Library (librera estndar de plantillas). Trmino relacionado
conC++.
TCPTransferControlProtocol(protocolodecontroldetransferencia).
UDPUserDatagramProtocol,protocolodedatagramadeusuario.
XML eXtended Markup Language, lenguaje extendido de marcado (basado en
etiquetas).
Bibliografa 273
BIBLIOGRAFA
[Allaramaju01]
ProfessionalJavaServerProgrammingJ2EE,1.3Edition
S.Allaramaju,C.Buest,M.Wilcox,S.Tyagi,R.Johnson,G.Watson.,A.
Williamson,J.Davies,R.Naggapan,A.Longshaw,P.Sarang,T.Jewell,A.
Toussaint
WroxPressLtd.,September2001
[Amir95]
TheTotemSingle-RingOrderingandMembershipProtocol
Y.Amir,L.E.Moser,P.M.Melliar-Smith,D.A.Agarwal,P.Ciarfella
ACMTransactionsonComputerSystems,Vol.13,No.4,November1995.
pag311-342
[Amir98]
TheSpreadWiseAreaGroupCommunicationSystem
Y.Amir,J.Stanton
TechnicalReportCNDS-98-4,TheCenterforNetworkingandDistributed
Systems,TheJohnsHopkinsUniversity
[Amoeba]
http://www.cs.vu.nl/pub/amoeba/
[Arjuna]
http://arjuna.ncl.ac.uk/
Bibliografa 274
[Babaoglu95]
GroupMembershipandViewSynchronyinPartitionableAsynchronous
DistributedSystems:Specifications
O.Baboglu,R.Davoli,A.Montresor
UniversityofBologna,TechnicalReportUBLCS-95-18,November1995
[Babaoglu96]
EnrichedViewSynchrony:AProgrammingParadigmforPartitionable
AsynchronousDistributedSystems
O.Babaoglu,A.Bartoli,G.Dini
TechnicalReport.DepartmentofComputerScience,UniversityOfBologna,
May1996
[Ban98]
JavaGroups-GroupCommunicationPatternsinJava
B.Ban
CornellUniversity,July1998
[Bast]
http://lsewww.epfl.ch/bast/
[Berson96]
Client/ServerArchitecture
A.Berson
McGrawHill,2
nd
Edition,March1996
[Birman85]
ReplicationandFault-ToleranceintheISISSystem
K.Birman
10thACMSymposiumonOperatingSystemsPrinciples,79-86.Operating
SystemsReview,19,5.December1985
[Birman87]
ReliableCommunicationinthePresenceofFailures
K.Birman,T.Joseph
ACMTransactionsonComputerSystems,February1987,Vol5,No1,pag
47-76
[Birman96]
BuildingSecureandReliableNetworkApplications
K.Birman
ManningPublications,1996
[Birman98]
Bimodalmulticast
K.Birman,M.Hayden,O.Ozkasap,M.Budiu,Y.Minski
TechnicalReportTR98-1665,CornellUniversity
Bibliografa 275
[Birman99]
BimodalMulticast
K.Birman,M.Hayden,O.Ozkasap,Z.Xiao,M.Budiu,Y.Minsky.
ACMTransactionsonComputerSystems.(May1999).Volume17,No.2
[Birrel84]
ImplementingRemoteProcedureCalls.
A.D.Birrell,B.J.Nelson
ACMTransactionsonComputerSystems,Vol2,No1,pag39-59,February
1984
[Budhiraja93]
DistributedSystems
N.Budhiraja,K.Marzullo,F.Schneider,S.Toueg
Addison-Wesley,2
nd
Edition,1993.Chapter8:ThePrimary-Backup
Approach,pag169-197
[Cactus]
http://www.cs.arizona.edu/cactus/index.html
[Chang84]
Reliablebroadcastprotocols
J.M.Chang,N.F.Maxemchuk
ACMTransComput.Systems,2,3(August1984),251-273
[Chou97]
BeyondFaultTolerance
T.C.K.Chou
IEEEComputer,April1997
[Christian91]
UnderstandingFault-TolerantDistributedSystem
F.Christian
CommunicationsoftheACM,February1991,Vol34,No2,pag56-78
[Chung98]
DCOMandCORBAsidebyside,StepbyStep,andLayerbyLayer
P.E.Chung,Y.Huang,S.Yajnik,D.Liang,J.C.Shih,Ch.Wang,Y.Wang
http://www.cs.wustl.edu/~schmidt/submit/Paper.html,1998
[Curtis97]
Java,RMIandCORBA
D.Curtis
http://www.omg.org,1997
Bibliografa 276
[Dolev96]
TheTransisApproachtoHighAvailabilityClusterCommunication
D.Dolev,D.Malki
CommunicationsofACM,39,4,April1996
[Dwoning98]
JavaRMI
T.B.Dwoning
IDGBooksWorldwide,February1998
[Dwork88]
Consensusinthepresenceofpartialsynchrony
C.Dwork,N.A.Lynch,L.Stockmeyer
JournaloftheACM,35(2):288-323,April1988
[Electra]
http://www.softwired.ch/people/maffeis/electra.html
[Ensemble]
http://www.cs.cornell.edu/Info/Projects/Ensemble/index.html
[Felber98]
TheCORBAObjectGroupService:AServiceApproachtoObjectGroupsin
CORBA
P.Felber
PhDthesisNumber1867,colePolytechniqueFdraledeLausanne,
Switzerland,1998.
[Fidge96]
FundamentalsofDistributedSystemObservation
C.J.Fidge
IEEESoftwareNovember1996
[Freeman99]
JavaSpacesPrinciples,PatternsandPractice
E.Freeman,S.Hupfer,K.Arnold
Addison-WesleyPubCo,June1999
[Friedman95]
StrongandWeakVirtualSynchronyinHorus
R.Friedman,R.Renesse
CornellUniversityTechnicalReportTR95-1537,August1995
[Gamma95]
DesignPatterns
E.Gamma,R.Helm,R.Johnson,J.Vlissides
AddisonWesleyLongman,1995
Bibliografa 277
[Garbinato97]
UsingtheStrategyDesignPatterntoComposeReliableDistributed
Protocols
B.Garbinato,R.Guerraoui
Proceedingsofthe3rdUSENIXConferenceonObject-Oriented
TechnologiesandSystems(COOTS97),Portland(Oregon),June1997
[Gelernter85]
GenerativeCommunicationsinLinda
D.Gelernter
ACMTransactionsonProgrammingLanguagesandSystems,Jauary1985,
Vol.7,N.1,pp80-112
[Gopalan98]
ADetailedComparisonofCORBA,DCOMandJava/RMI
R.Gopalan
http://www.execpc.com/~gopalan/misc/compare.html,1998
[Gray93]
TransactionProcessing:ConceptsandTechniques
J.Gray,A.Reuter
MorganKaufmannPublishers,SanMatero,CA,1993
[Guerraoui95]
TransactionmodelvsVirtualSynchronymodel:bridgingthegap
R.Guerraoui,A.Schiper
Proc.InternationalWorkshopTheoryandPracticeinDistributedSystems,
SpringerVerlag,LNCS938,1995
[Hayden98]
TheEnsembleSystemCornellUniversity
M.Hayden
TechnicalReport,TR98-1662,January1998
[Horus]
http://www.cs.cornell.edu/Info/Projects/Horus/index.html
[Ibus]
http://www.softwired-inc.com/products/ibus/
[Isis]
http://www.cs.cornell.edu/Info/Projects/Isis/index.html
[JavaGroups]
http://www.cs.cornell.edu/Info/People/bba/javagroups.html
[JGroup]
http://www.cs.unibo.it/projects/jgroup/
Bibliografa 278
[Jimnez99]
TransLib:AnAda95ObjectOrientedFrameworkforBuildingTransactional
Applications
R.Jimnez,MPatio,S.Arvalo,F.Ballesteros
SpecialIssueonDevelopingFault-TolerantSystemswithAda95,Intl.
JournalonComputerSystems:ScienceandEngineering,1999
[Juric00]
Java2RMIandIDLcomparison
M.B.Juric,I.Rozman
JavaReport,February2000
[Kaashoek91]
GroupcommunicationintheAmoebadistributedoperatingsystem
M.F.Kaashoek,A.S.Tanenbaum
InProceedingsoftheIEEE11
th
InternationalConferenceonDistributed
ComputingSystems(Arlington,Texas,1991).IEEE,NewYork,882-891
[Lamport82]
Fail-stopprocessors:Anapproachtodesigningfault-tolerantcomputing
systems
L.Lamport,R.E.Shostak,M.C.Pease
ACMTransactionsonProgrammingLanguagesandSystems(TOPLAS),
1982,Vol4,No3:pag382-401
[Leffler89]
TheDesignandImplementationofthe4.3BSDUNIXOperatingSystem
S.J.Leffler,M.McKusick,M.Karels,J.Quaterman
Addison-Welsey,1989
[Little00]
IntegratingGroupCommunicationwithTransactionsforImplementing
PersistentReplicatedObjetcs
M.Little,S.Shrivastava
LNCS1752,2000,pag238-253
[Maestro]
http://simon.cs.cornell.edu/Info/Projects/Ensemble/Maestro/Maestro.html
[Maffeis97]
ConstructingReliableDistributedCommunicationSystemswithCORBA
S.MaffeisD.Schmidt
IEEECommunicationsMagazine14(2),February1997
Bibliografa 279
[Maguire93]
WritingSolidCode
S.Maguire
MicrosoftPress,May1993
[Malki94]
UniformActionsinAsynchronousDistributedSystems
D.Malki,K.Birman,A.Ricciardi,A.Schiper
Proc.Ofthe13
th
AnnualACMSymposiumonPrinciplesofDistributed
Computing(PODC),LosAngeles,August14-17,1994
[Malloth96]
ConceptionandImplementationofaToolkitforBuildingFault-Tolerant
DistributedApplicationsinLargeScaleNetworks
C.Malloth
PhDThesisNo.1557,SwissFederalInstituteofTechnologyofLausanne
(Switzerland)(EcolePolytechniqueFdraledeLausanne).September1996
[Marzullo96]
NILE:Wide-areacomputingforhighenergyphysics
K.Marzullo,M.Ogg,A.Ricciardi,A.Amoroso,F.A.Calkins,E.Rothfus
InProc.7thACMSIGOPSEuropeanWorkshop,pag49-54,Connemara,
Ireland,2-4September1996.ACM
[Montresor98]
TheJgroupReliableDistributedObjectModel
A.Montresor
ProceedingsoftheSecondIFIPWG6.1InternationalWorkingConference
onDistributedApplicationsandInteroperableSystems,Helisinki,Finland,
June1999
[Moser95]
TheTotemSystem
L.E.Moser,P.M.Melliar-Smith,D.A.Agarwal,R.K.Budhia,C.A.
Lingley-Papadopoulos,T.P.Archambault
Proceedingsofthe25thInternationalSymposiumonFaultTolerant
Computing,Pasedena,CA(June1995),61-66
[Moss85]
NestedTransactions:AnApproachtoReliableDistributedComputing
J.Moss
MITPress,Cambridge,MA,1985
Bibliografa 280
[Neumann56]
Probabilisticlogicsandthesynthesisofreliableorganismsfromunreliable
components
J.vonNeumann
AutomataStudies,PrincetonUniversityPress,1956,pag43-98
[Nile]
http://www.nile.cornell.edu/
[OMG00]
FaultTolerantCORBASpecification,v1.0
OMGDocumentptc/2000-04-04.http://www.omg.org/cgi-bin/doc?ptc/2000-
04-04
[OMG97]
CORBAservices:CommonObjectServicesSpecification
OMG,1997
[OMG98]
TheCommonObjectRequestBroker:ArchitectureandSpecification
OMG,February1998
[OMG99]
CORBA/IIOP2.3.1Specification,formal/99-10-07
OMG,October1999
[Oram01]
Peer-to-Peer.HarnessingthePowerofDisruptiveTechnologies
OramA.(editor)
OReilly,March2001
[Orfali97]
InstantCORBA
R.Orfali,D.Harkey,J.Edwards
WileyComputerPublishing,1997
[Parrington95]
TheDesignandImplementationofArjuna
G.D.Parrington,S.K.Shrivastava,S.M.Wheater,M.C.Little
USENIXComputingSystemsJournal,Vol8,No3,1995
[Patio00]
ScalableReplicationinDatabaseClusters
M.Patio,R.Jimnez,B.Kemme,G.Alonso
Proc.OftheInt.Conf.OnDistributedComputingDISC00,(LNCS1914),
Toledo,October2000
Bibliografa 281
[Pavn00]
ConditionsfortheStateTransferonVirtualSynchronousSystems
J.Pavn,LM.Pea
ProceedingsofThe10thInternationalConferenceonComputingand
InformationICI2000,Kuwait,Noviembre18-21,2000(previstasu
publicacinenelnmero2023deLNCS:
http://www.springer.de/comp/lncs/fcp2000.html)
[Pavn02]
ActiveReplicationOfSoftwareComponents
J.Pavn,LM.Pea
Aceptadoenel3rdInternationalWorkshoponSoftwareEngineeringand
Middleware(SEM2002),Orlando,Florida,20-21demayode2002.
(http://www.crii.uninsubria.it/sem2002/)
[Pea00]
ReplicacindeObjetosDistribuidos
LM.Pea,J.Pavn
1erTallerdeTrabajoenIngenieradelSoftwarebasadaenComponentes
Distribuidos,IScDIS2000,Valladolid,9Noviembre2000.Universidadde
Extremadura,Dep.Informtica,InformeTcnicoTR12/2000(pp.89-98)
[Pea97]
FiabilidadyCalidaddeServicioenlaArquitecturaCORBA
LM.Pea
ActasdelasVJornadasdeConcurrencia,Vigo,Junio1997,pp.381-388
[Pea99]
Sensei:TransferenciadeEstadoenGruposdeObjetosDistribuidos
LM.Pea,J.Pavn
ComputacinySistemasVol.2,No.4,pp.191-201,Abril-Junio1999(versin
extendidadelaponenciapresentadaenelSimposioEspaoldeInformtica
Distribuida,SEID99,SantiagodeCompostela,24-26Febrero1999;actas
editadasporTrculoEdicins,1999,pp.67-76).
[Peterson89]
Preservingandusingcontextinformationininterprocesscomunication
L.L.Peterson,N.C.Buchholz,R.D.Schlichting
ACMTransComput.System7,3(August1989),217-246
[Philippsen97]
JavaPartyTransparentRemoteObjectsinJava
M.Phillipsen,M.Zenger
Concurrency:PracticeandExperience,9(11):1125-1242,1997
Bibliografa 282
[Phoenix]
http://lsewww.epfl.ch/projets/phoenix/index.html
[Rajagopalan89]
Atoken-basedprotocolforreliable,orderedmulticastcommunication
B.Rajagopalan,P.K.McKinley
InProceedingsoftheIEEE8
th
SymposiumonReliableDistributedSystems
(Seattle,Wash.,1989).IEEE,NewYork,84-93
[Relacs]
http://www.cs.unibo.it/projects/relacs.html
[Renesse96]
Horus,aflexibleGroupCommunicationSystem
R.vanRenesse,K.Birman,S.Maffeis
CommunicationsoftheACM,April1996
[Ricciardi93]
UnderstandingPartitionsandthe"NoPartition"Assumption
A. Ricciardi,A.Schiper,K.Birman
IEEEProcFourthWorkshoponFutureTrendsofDistributedSystems,
Lisbon,September22-24,1993
[RMP]
http://research.ivv.nasa.gov/RMP/
[Rodrigues92]
xAMp:aMulti-primitiveGroupCommunicationsService
L.Rodrigues,P.Verssimo
Proceedingsofthe11thSymposiumOnReliableDistributedSystems,
October1992,Houston,Texas
[Sabel94]
SimulatingFail-StopinAsynchronousDistributedSystems
L.Sabel,K.Marzullo
Proceedingsofthe13
th
SymposiumonReliableDistributedSystems,October
1994
[Schiper96]
FromGroupCommunicationtoTransactionsinDistributedSystems
A.Schiper,M.Raynal
CommunicationsoftheACM,Vol.39No.4,April1996.pag84-87
[Schlichting93]
ACommunicationSubstrateforFault-tolerantDistributedPrograms
S.Mishra,L.Peterson,R.Schlichting
DistributedSystemEngineering,vol.1,pp.87-103,December1993
Bibliografa 283
[Schmidt95a]
Objectinterconnections.IntroductiontoDistributedObjectComputing
D.Schmidt,S.Vinoski
SIGSC++ReportMagazine,Vol7,No1,January1995
[Schmidt95b]
Objectinterconnections.ComparingAlternativeServerDistributed
ProgrammingTechniques.
D.Schmidt,S.Vinoski
SIGSC++ReportMagazine,Vol7,No8,October1995
[Schmidt97]
Objectinterconnections.OMGEventObjectService
D.Schmidt,S.Vinoski
SIGSC++ReportMagazine,Vol9,No2,February1997
[Schneider90]
Implementingfault-tolerantservicesusingthestatemachineapproach:A
tutorial
F.Schneider
ACMComputingSurveys,22(4):299-319,December1990
[Schneider93]
DistributedSystems
F.Schneider
Addison-Wesley,2
nd
Edition,1993.Chapter7:RplicationManagement
usingtheState-MachineApproach,pag169-197
[Sensei]
http://grasia.fdi.ucm.es/sensei
[Sessions97]
COMandDCOM:MicrosoftsvisionforDistributedObjects
R.Sessions
JohnWiley&Sons,1997
[Spinglass]
http://www.cs.cornell.edu/Info/Projects/Spinglass/index.html
[Spread]
http://www.spread.org/
[SSL]
http://home.netscape.com/eng/security
Bibliografa 284
[Stevens90]
UNIXNetworkProgramming
W.RStevens
EnglewoodCliffs,NJ:PrenticeHall,1990
[SUN99]
JavaMessagingService
SUN,version1.0.2,November1999
[Tanembaum91]
TheAmoebaDistributedOperatingSystem-AStatusReport
A,Tanenbaum,M.Kaashoek,R.vanRenesse,H.Bal
ComputerCommunications,vol.14,pp.324-335,July/August1991
[Totem]
http://beta.ece.ucsb.edu/totem.html
[TLS]
http://www.ietf.org/rfc/rfc2246.txt
[Transis]
http://www.cs.huji.ac.il/labs/transis/index.html
[Vaysburd98]
BuildingReliableInteroperableDistributedObjectswiththeMaestroTools
CornellUniversityTechnicalReport,TR98-1678,May1998
[Vogels98]
TheDesignandArchitectureoftheMicrosoftClusterService
W.Vogels,D.Dumitriu,K.Birman,R.Garnache,M.Massa,R.Short,J.
Vert,J.Barrera,J.Gray
ProceedingsofFTCS98,June1998,Munich,Germany
[W3C00]
ExtensibleMarkupLanguaje(XML)1.0(SecondEdition)
http://www.w3.org/TR/REC-xml
[W3C01]
SOAPVersion1.2Part0:Primer
http://www.w3.org/TR/soap12-part0/
[White75]
AHigh-LevelFrameworkforNetwork-BasedResourceSharing
J.E.White
RFC707,December1975
[xAmp]
http://www.navigators.di.fc.ul.pt/xAMp/xAMp.html
Bibliografa 285

Corb Aaaaa Sense I

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Corb Aaaaa Sense I

Caricato da

Copyright:

Formati disponibili

TCNICASDEDESARROLLODEAPLICACIONES

Las tcnicas de tolerancia a fallos en arquitecturas distribuidas cliente/servidor

Fault Tolerance software techniques for distributed client/server architectures (like

El miembro que recibe el estado debe procesar sus propios mensajes

Esta ltima simplificacin [7] es vlida para grupos que envan

Un objeto debe implementar la interfaz GroupMember para poderpertenecera

El primer parmetro indica el receptor de los mensajes de error que, por

Potrebbero piacerti anche