Remodelando o ACOM no Modelo Motherboard

Esta se¸c˜ao apresenta uma solu¸c˜ao para facilitar as extens˜oes do ACOM. Ela reestrutura a arquitetura do ACOM incluindo elementos abertos de mais alto n´ıvel propostos pelo modelo motherboard. Essa reestrutura¸c˜ao do ACOM ser´a chamada de ACOMm. Ao

104 Cap´ıtulo 6. Servi¸cos de Transa¸c˜oes Abertos

inv´es de ter que analisar e manipular o c´odigo fonte (classes, componentes, interfaces e conex˜oes), o usu´ario do ACOMm passa a manipular elementos de mais alto n´ıvel do mod- elo motherboard, como demultiplexadores, jumpers e slots. Por exemplo, no ACOMm, para definir a decis˜ao de efetiva¸c˜ao como s´ıncrona o usu´ario precisa somente fornecer um parˆametro que diz “a decis˜ao de commit ´e s´ıncrona” ao inv´es de ter que realizar a tarefa de baixo n´ıvel “conectar a interface commit do componente CommitManager `a interface

sync do componente CommunicationManager ”.

O Mecanismo de Efetiva¸c˜ao

O mecanismo de efetiva¸c˜ao do ACOMm ´e mostrado na Figura 6.11. Ele reutiliza os com- ponentes do ACOM incluindo um conjunto de elementos abertos do modelo motherboard (jumpers e slots). No ACOMm, a defini¸c˜ao de diferentes tipos de protocolos de efetiva¸c˜ao passa a ser poss´ıvel somente atrav´es da manipula¸c˜ao desses elementos abertos.

Para definir protocolos de efetiva¸c˜ao, s˜ao definidos elementos abertos tanto na arquite- tura do coordenador como na do participante. Os elementos abertos do coordenador s˜ao (Figura 6.11(a)):

JSP . Jumper que pode ser ativado para que o pedido de voto (prepare) do coordenador seja realizado de forma s´ıncrona ou desativado quando o protocolo n˜ao possui a fase de pedido de voto (como no protocolo 1PC)13_.

DC . Demultiplexador que permite que a decis˜ao de efetiva¸c˜ao seja configurada como s´ıncrona ou ass´ıncrona. Para s´ıncrona, o parˆametro de sele¸c˜ao tem o valor “BCS” e, para ass´ıncrona, o valor “BCA”.

DA . Demultiplexador que permite que a decis˜ao de cancelamento seja configurada como s´ıncrona ou ass´ıncrona. Para s´ıncrona, o parˆametro de sele¸c˜ao tem o valor “BAS” e, para ass´ıncrona, o valor “BAA”.

DIL . Demultiplexador que permite que informa¸c˜oes de inicializa¸c˜ao do protocolo sejam registrados no log como force ou como non-force. Para force, o parˆametro de sele¸c˜ao tem o valor “BIF” e, para non-force, o valor “BIN”. Caso n˜ao haja registro de inicializa¸c˜ao, deve-se fornecer o valor “NULL”.

JCF . Jumper que pode ser ativado para que a decis˜ao de efetiva¸c˜ao seja registrada no log como force ou desativado quando n˜ao h´a registro da decis˜ao de efetiva¸c˜ao. 13

Como se pode notar, a arquitetura n˜ao disponibiliza a op¸c˜ao de pedido de voto ass´ıncrono. Isso se baseia no fato de que quando existe pedido de voto, ele ser´a sempre s´ıncrono por ele exigir a resposta (voto) dos participantes.

sel D c CommitMng prepare commit abort init_log commit_log abort_log end_commit_log end_abort_log ComunMng LogMng sync asyn force non_force sel D A sel D IL sel D A L sel D E C sel D E A JSP JCF BDC BDA BDIL BDAL BDEC BDEA BCS BCA BAS BAA BIF BIN BAF BAN BECF BECN BEAF BEAN LogMng force non_force sel D C P sel D A P BCFP BCNP BAFP BANP R e s o u rc e M n g vote_log commit_log abort_log JVF BDCP BDAP (a) Coordenador (b) Participante

Figura 6.11: O Mecanismo de Efetiva¸c˜ao do ACOM no Modelo Motherboard DAL . Demultiplexador que permite que a decis˜ao de cancelamento do protocolo seja

registrada no log como force ou como non-force. Para force, o parˆametro de sele¸c˜ao tem o valor “BAF” e, para non-force, o valor “BAN”. Caso n˜ao haja registro de inicializa¸c˜ao, deve-se fornecer o valor “NULL”.

DEC . Demultiplexador que permite que o final do protocolo de transa¸c˜oes efetivadas seja registrada no log como force ou como non-force. Para force, o parˆametro de sele¸c˜ao tem o valor “BECF” e, para non-force, o valor “BECN”. Caso n˜ao haja registro de inicializa¸c˜ao, deve-se fornecer o valor “NULL”.

DEA . Demultiplexador que permite que o final do protocolo de transa¸c˜oes canceladas seja registrada no log como force ou como non-force. Para force, o parˆametro de sele¸c˜ao tem o valor “BEAF” e, para non-force, o valor “BEAN”. Caso n˜ao haja

106 Cap´ıtulo 6. Servi¸cos de Transa¸c˜oes Abertos

registro de inicializa¸c˜ao, deve-se fornecer o valor “NULL”. Os elementos abertos do participante s˜ao (Figura 6.11(b)):

JV F . Jumper que pode ser ativado para que o voto do participante seja registrado no log como force ou desativado quando n˜ao h´a registro do voto.

DCP . Demultiplexador que permite que a decis˜ao de efetiva¸c˜ao do protocolo seja reg- istrada no log como force ou como non-force. Para force, o parˆametro de sele¸c˜ao tem o valor “BCFP” e, para non-force, o valor “BCNP”. Caso n˜ao haja registro de inicializa¸c˜ao, deve-se fornecer o valor “NULL”.

DAP . Demultiplexador que permite que a decis˜ao de cancelamento do protocolo seja registrada no log como force ou como non-force. Para force, o parˆametro de sele¸c˜ao tem o valor “BAFP” e, para non-force, o valor “BANP”. Caso n˜ao haja registro de inicializa¸c˜ao, deve-se fornecer o valor “NULL”.

A representa¸c˜ao XML da MD-View do mecanismo de efetiva¸c˜ao do ACOMm ´e mostrada na Figura 6.12 e na Figura 6.13. A primeira figura apresenta a parte do coordenador e a segunda figura apresenta a parte do participante.

<?xml version=’1.0 ’ e n c o d i n g=’UTF -8’?> <a r c h i t e c t u r e i d=’ACOM ’>

<component i d=’CommitMng ’ s o u r c e=’ACOM . CommitManager ’/>

<component i d=’ComunMng ’ s o u r c e=’ACOM . CommunicationManager ’/> <component i d=’LogMng’ s o u r c e=’ACOM . LogManager ’/>

<jumper i d=’JSP ’ c l i e n t=’ CommitMng ’

s e r v e r=’ComunMng ’ i n t f=’ACOM . ISyncPrepare ’/>

<demux i d=’DC’ out=’BCS , BCA ’/>

<bind i d=’BDC ’ c l i e n t=’CommitMng ’ s e r v e r=’DC’ i n t f=’ACOM . IComm’/> <bind i d=’BCS ’ c l i e n t=’DC’ s e r v e r=’ComunMng ’ i n t f=’ACOM . ISync’/> <bind i d=’BCA ’ c l i e n t=’DC’ s e r v e r=’ComunMng ’ i n t f=’ACOM . IAsyn’/>

<demux i d=’DA’ out=’BAS , BAA ’/>

<bind i d=’BDA ’ c l i e n t=’CommitMng ’ s e r v e r=’DA’ i n t f=’ACOM . IAbort’/> <bind i d=’BAS ’ c l i e n t=’DA’ s e r v e r=’ComunMng ’ i n t f=’ACOM . ISync’/> <bind i d=’BAA ’ c l i e n t=’DA’ s e r v e r=’ComunMng ’ i n t f=’ACOM . IAsyn’/>

<demux i d=’DIL ’ out=’BIF , BIN ’/>

<bind i d=’BDIL ’ c l i e n t=’CommitMng ’ s e r v e r=’DIL ’ i n t f=’ACOM . IILog’/> <bind i d=’BIF ’ c l i e n t=’DIL ’ s e r v e r=’LogMng’ i n t f=’ACOM . IForce’/> <bind i d=’BIN ’ c l i e n t=’DIL ’ s e r v e r=’LogMng’ i n t f=’ACOM . INonForce ’/>

<jumper i d=’JCF ’ c l i e n t=’ CommitMng ’

s e r v e r=’LogMng’ i n t f=’ACOM . ICommitForce ’/>

<demux i d=’DAL ’ out=’BAF , BAN ’/>

<bind i d=’BDAL ’ c l i e n t=’CommitMng ’ s e r v e r=’DAL ’ i n t f=’ACOM . IAbLog’/> <bind i d=’BAF ’ c l i e n t=’DAL ’ s e r v e r=’LogMng’ i n t f=’ACOM . IForce’/> <bind i d=’BAN ’ c l i e n t=’DAL ’ s e r v e r=’LogMng’ i n t f=’ACOM . INonForce ’/>

<demux i d=’DEC ’ out=’BECF , BECN ’/>

<bind i d=’BDEC ’ c l i e n t=’CommitMng ’ s e r v e r=’DEC ’ i n t f=’ACOM . IECLog’/> <bind i d=’BECF ’ c l i e n t=’DEC ’ s e r v e r=’LogMng’ i n t f=’ACOM . IForce’/> <bind i d=’BECN ’ c l i e n t=’DEC ’ s e r v e r=’LogMng’ i n t f=’ACOM . INonForce ’/>

<demux i d=’DEA ’ out=’BEAF , BEAN ’/>

<bind i d=’BDEA ’ c l i e n t=’CommitMng ’ s e r v e r=’DEA ’ i n t f=’ACOM . IEALog’/> <bind i d=’BEAF ’ c l i e n t=’DEA ’ s e r v e r=’LogMng’ i n t f=’ACOM . IForce’/> <bind i d=’BEAN ’ c l i e n t=’DEA ’ s e r v e r=’LogMng’ i n t f=’ACOM . INonForce ’/> </ a r c h i t e c t u r e>

 

108 Cap´ıtulo 6. Servi¸cos de Transa¸c˜oes Abertos



<?xml version=’1.0 ’ e n c o d i n g=’UTF -8’?> <a r c h i t e c t u r e i d=’ACOM ’>

<component i d=’ ResourceMng ’ s o u r c e=’ACOM . ResourceManager ’/> <component i d=’LogMng’ s o u r c e=’ACOM . CommitManager ’/>

<jumper i d=’JVF ’ c l i e n t=’ResourceMng ’

s e r v e r=’LogMng’ i n t f=’ACOM . ICommitForce ’/> <demux i d=’DCP ’ out=’BCFP , BCNP ’/>

<bind i d=’BDCP ’ c l i e n t=’ResourceMng ’ s e r v e r=’DCP ’ i n t f=’ACOM . ICLog’/> <bind i d=’BCFP ’ c l i e n t=’DCP ’ s e r v e r=’LogMng’ i n t f=’ACOM .IForce’/> <bind i d=’BCNP ’ c l i e n t=’DCP ’ s e r v e r=’LogMng’ i n t f=’ACOM . INonForce ’/> <demux i d=’DAP ’ out=’BAFP , BANP ’/>

<bind i d=’BDAP ’ c l i e n t=’ResourceMng ’ s e r v e r=’DA’ i n t f=’ACOM . IAbLog’/> <bind i d=’BAFP ’ c l i e n t=’DAP ’ s e r v e r=’LogMng’ i n t f=’ACOM .IForce’/> <bind i d=’BANP ’ c l i e n t=’DAP ’ s e r v e r=’LogMng’ i n t f=’ACOM . INonForce ’/> </ a r c h i t e c t u r e>

 

Figura 6.13: MD-View do Mecanismo de Efetiva¸c˜ao do ACOM (Participante)

O Gerenciador de Comportamento

Al´em do mecanismo de efetiva¸c˜ao, o gerenciador de comportamento do ACOM tamb´em foi reestruturado no modelo motherboard. Essa reestrutura¸c˜ao teve o objetivo de tornar o ACOM extens´ıvel no que diz respeito `a inclus˜ao de novas pol´ıticas de adapta¸c˜ao e de novos configuradores de protocolo de efetiva¸c˜ao. A principal medida nesse sentido foi a de realizar uma separa¸c˜ao entre o c´odigo que implementa as pol´ıticas de adapta¸c˜ao e o c´odigo que implementa o componente BehaviourAwareness. Dessa forma, novas pol´ıticas de adapta¸c˜ao poderiam ser inclu´ıdas sem a necessidade de alterar o c´odigo do

BehaviourAwareness.

A reestrutura¸c˜ao do gerenciador de comportamento ´e mostrada na Figura 6.14. Para obter maior facilidade de extens˜ao, ele conta com a inclus˜ao de dois elementos abertos do modelo motherboard: o slot SPolicies e o slot SConfig. Esses slots s˜ao descritos a seguir: SP olicies. Esse slot m´ultiplo foi a solu¸c˜ao adotada para se separar as pol´ıticas de adapta¸c˜ao

do componente BehaviourAwareness. Nessa estrutura, cada pol´ıtica de adapta¸c˜ao passa a ser implementada como um componente individual que pode ser conectado ao slot SPolicies. Para se definir um componente de pol´ıtica, deve-se implementar a interface provida IRateEvent – atrav´es da qual o BehaviourAwareness passa in- forma¸c˜oes sobre as taxas de efetiva¸c˜ao e de cancelamento – e a interface requerida

TrnF ac tory B e hA w are nes s IB e hA w a ren ess IL isten er M FP ro xy IListe ne r IR ateE ven t TrnF actory IC onfig IR e co nfig IR a te E ve nt IC o nfig S P olicies* S C on fig * IR e co nfig

IM oth erF ram e IM othe rFra m e

BL

BR

BC

BR C

BM F

Figura 6.14: O Gerenciador de Comportamento do ACOM no Modelo Motherboard

IConfig – atrav´es da qual o componente de pol´ıtica dispara a a¸c˜ao de reconfigura¸c˜ao

do protocolo de efetiva¸c˜ao.

SConf ig. Nesse slot devem ser conectados os configuradores de protocolos de efetiva¸c˜ao. Cada configurador ´e respons´avel por manipular os elementos abertos do mecanismo de efetiva¸c˜ao do ACOMm de forma que ele passe a implementar o protocolo de efetiva¸c˜ao desejado. Um componente configurador deve implementar a interface provida IReconfig – a partir da qual ele recebe a autoriza¸c˜ao para reconfigurar o mecanismo de efetiva¸c˜ao – e a interface requerida IMotherFrame – a partir da qual o configurador acessa e manipula os elementos abertos do mecanismo de efetiva¸c˜ao (demultiplexadores e jumpers) de forma a configur´a-lo de acordo com o protocolo correspondente.

A representa¸c˜ao XML da MD-View do gerenciador de comportamento ´e mostrada na Figura 6.15.

Nas se¸c˜oes a seguir ser´a mostrado como o ACOMm possui a flexibilidade necess´aria para ser configurado de acordo com requisitos de diferentes cen´arios.