Trabalho Prtico de Avaliao n1

Alunos: N 99999 xxxxxxxxxxxxxxxxx N 99999 xxxxxxxxxxxxxxxxx N 99999 xxxxxxxxxxxxxxxxx

1 de Dezembro de 2011

ndice
1 2 Introduo ............................................................................................................................. 3 Requisitos .............................................................................................................................. 3 2.1 2.2 3 No Funcionais .............................................................................................................. 3 Funcionais...................................................................................................................... 3

Arquitetura ............................................................................................................................ 4 3.1 3.2 3.3 3.4 3.5 Esquema conceptual ..................................................................................................... 4 Arquitetura servidor ...................................................................................................... 4 Arquitetura cliente ........................................................................................................ 5 Esquema de interaes ................................................................................................. 6 Estruturas de dados ...................................................................................................... 6 Informao sobre medicamentos ......................................................................... 6 Lista de farmcias .................................................................................................. 7 Lista de servidores ................................................................................................. 7

3.5.1 3.5.2 3.5.3 4

Pontos-chave da implementao .......................................................................................... 7 4.1 4.2 4.3 4.4 Propagao do registo das farmcias ........................................................................... 7 Tratamento da falha de um servidor ............................................................................ 7 Reintegrao de um servidor reinicializado / Boot do servidor.................................... 8 Falha de um cliente (farmcia) ...................................................................................... 8 Detetada ao pesquisar (ao interrogar servidor sobre famlia) .............................. 8 Detetada ao consultar produtos (ao inquirir produtos farmcia) ........................ 8

4.4.1 4.4.2 4.5 5 6

Integrao de um novo servidor ................................................................................... 8

Outros aspetos de implementao ....................................................................................... 9 Outros aspetos conceptuais ................................................................................................ 10 6.1 6.2 6.3 6.4 6.5 Tratamento de excees ............................................................................................. 10 Tempos de vida dos objetos........................................................................................ 10 Modos de ativao dos objetos .................................................................................. 10 Protocolos de comunicao ........................................................................................ 10 Controlo de concorrncia............................................................................................ 11

Pontos fortes e fracos ......................................................................................................... 12 7.1 Aspetos a melhorar ..................................................................................................... 12

Prottipo de demonstrao ................................................................................................ 12

Nota: este relatrio foi redigido respeitando o novo acordo ortogrfico.

1 Introduo
Foi-nos proposto desenvolver uma aplicao distribuda que simule um ambiente em que vrias farmcias interagem com um anel de servidores. O anel concilia a necessidade de, por um lado, o objeto alojado no servidor ter estado e, por outro lado, conferir alguma tolerncia a falhas aplicao. A informao encontra-se replicada por todos os servidores do anel. Uma farmcia pede informaes ao servidor da sua zona sobre outras farmcias e, aps ter obtido o contacto dessas, comunica diretamente com elas. O ambiente de desenvolvimento utilizado foi o .NET Remoting, Visual Studio 2010 Ultimate e C#.

2 Requisitos
2.1 No Funcionais
R1 O sistema est dividido em zonas; cada zona contm 1 servidor e vrias farmcias R2 Os servidores de zona esto ligados em anel R3 Cada farmcia contm um objeto StockManager que guarda informao sobre o stock de medicamentos R4 Os medicamentos esto agrupados em famlias R5 Cada farmcia s conhece o servidor da sua zona

2.2 Funcionais
R6 Permitir o registo da farmcia no servidor R7 StockManager aceita pedidos remotos R8 Permitir o de-registo da farmcia do servidor R9 Registo/de-registo tm de ser sincronizados entre os vrios servidores, seguindo o anel R10 A farmcia ao registar-se deve indicar as famlias de produtos que tem e o seu objeto StockManager R11 Uma farmcia pode interrogar o servidor sobre famlias de produtos: obtm uma lista de StockManagers que contm a famlia pretendida R12 Aps conhecer um StockManager, uma farmcia pode inquirir informao sobre produtos a essa outra farmcia (StockManager) R13 O sistema deve fazer a reconfigurao do anel dinamicamente quando um servidor falha R14 Uma farmcia que deteta falha noutra farmcia deve informar servidor R15 A falha do cliente (farmcia) deve ser propagada no anel R16 Aplicao cliente deve mostrar os pedidos que o StockManager est a satisfazer, em tempo real R17 Anel de servidores deve poder ser aumentado dinamicamente

3 Arquitetura
3.1 Esquema conceptual

Este esquema foi elaborado na fase inicial do desenvolvimento e no essencial manteve-se.

3.2 Arquitetura servidor

Mtodos e Atributos AtendePedidosS registaFarmacia retiraFarmacia informaSobreFamilia desactivaFarmacia *(acrescentado posteriormente) listaFarmacias lista de proxies de StockManagers listaServidores lista de proxies de servidores proximoServidor prximo servidor no anel ToleranciaFalhasS retiraServidor *(implcito ao funcionamento) integraServidor *(implcito ao funcionamento)

Algoritmos registaFarmacia / retiraFarmacia - acrescenta-a lista de farmcias - chama mtodo do servidor seguinte (registaFarmacia) para informar sobre o registo daquela farmcia Ou: - verifica se j deu a volta informaSobreFamilia - pergunta a todas as farmcias se tm aquela famlia - constri lista de proxies dos StockManagers - devolve a lista ao cliente retiraServidor / integraServidor - retira servidor da lista - actualiza proximoServidor - envia a lista ao servidor seguinte desactivaFarmacia - confirma se o StockManager sinalizado est de facto indisponvel - em caso afirmativo: - retira StockManager da lista de farmcias - propaga a nova lista - devolve true se confirmou a indisponibilidade

Parametros void registaFarmacia(ElemListaFarmacias) void retiraFarmacia(ElemListaFarmacias) listaStockManagers informaSobreFamilia(famlia) booleano desactivaFarmacia(ElemListaFarmacias)

3.3 Arquitetura cliente

Farmcia enquanto cliente Recproco registaFarmacia (mtodo servidor) informaSobreFamilia (mtodo servidor) informaSobreProdutos (mtodo StockManager) desactivaFarmacia (mtodo servidor) aceitaEncomenda (mtodo StockManager) *apenas para repor stocks Funcionalidade Pedir registo no servidor Interrogar servidor sobre famlia Inquirir produtos farmcia Informar servidor sobre farmcia com falha Encomendar produtos/atualizar stock Vender produto / Comprar produto

StockManager (farmcia enquanto servidor) informaSobreProdutos temFamilia? aceitaEncomenda ping *(acrescentado posteriormente) servidorDown *(acrescentado posteriormente) servidorUp *(acrescentado posteriormente)

3.4 Esquema de interaes

Este o esquema bsico de funcionamento do sistema: - O cliente regista-se no servidor, indicando um StockManager - Outro cliente pede ao servidor informaes sobre famlias; o servidor devolve-lhe proxies de StockManagers - Na posse dos proxies, o cliente pode inquirir diretamente StockManagers de outras farmcias Est aqui implcita a utilizao de Network Pointers, que o centro do funcionamento de todo este sistema.

3.5 Estruturas de dados

3.5.1 Informao sobre medicamentos StockManager Array Familias Familia Nome Array Produtos

Produto Nome Preo Quantidade 3.5.2 Lista de farmcias ElemListaFarmacias StockManager Zona Id Esta estrutura partilhada pelo cliente e pelo servidor. 3.5.3 Lista de servidores ElemListaServidores ServidorFarmacias Zona Uri //*s usado no boot do servidor Este elemento utilizado pelo servidor, na lista interna de servidores.

4 Pontos-chave da implementao
4.1 Propagao do registo das farmcias
Quando uma farmcia se regista no num servidor, esse servidor tem de propagar o registo aos restantes servidores do anel. Isto feito pelo mtodo registaFarmacia: O mtodo aceita um ElemListaFarmacias, adiciona-o lista de farmcias do servidor e invoca o mtodo registaFarmacia do prximo servidor. Os pontos relevantes so: - Quando o novo elemento d a volta ao anel gera-se um deadlock. Isto acontece porque o servidor est espera do retorno da chamada e no pode responder ao outro servidor que agora o chama a si A soluo que encontrmos foi fazer uma chamada assncrona ao prximo servidor; - A base da recurso acontece quando o servidor original recebe um pedido de registo de farmcia. O servidor deteta isto verificando que j contm o novo elemento na sua lista de farmcias.

4.2 Tratamento da falha de um servidor

A falha de um servidor detetada quando, durante a propagao de um registo de farmcia, um dado servidor K no obtm resposta do servidor K+1. O algoritmo de tratamento da falha segue os seguintes passos: - Informa farmcias do K+1 que ele est inoperacional (invoca mtodo servidorDown) - Redireciona o prximo servidor para K+2 - Atualiza a lista de servidores, removendo o servidor inoperacional (continua na pgina seguinte)

- Propaga a nova lista de servidores aos restantes servidores - Retoma a propagao da farmcia aps reconfigurar o anel de notar que a falha detetada durante o callback do registaFarmacia. Logo, no era possvel, a partir de um mtodo static, aceder ao mtodo da instncia que trata a falha Resolvemos este problema passando a prpria instncia como estado do IAsyncResult.

4.3 Reintegrao de um servidor reinicializado / Boot do servidor

A reintegrao de um servidor no anel feita pelo prprio servidor durante o boot, como explicado de seguida: - O servidor carrega a partir de um ficheiro XML a lista inicial de servidores - Tenta contactar algum desses servidores - Logo que consegue, pede a lista de servidores atual - Adiciona-se ao fim da lista e propaga a alterao - Contacta as farmcias da sua zona avisando que est de novo operacional (invoca mtodo servidorUp) - Caso entretanto (pode ter passado algum tempo) alguma farmcia da sua zona esteja inoperacional, deteta-o e propaga Este foi o algoritmo mais rduo de desenvolver em todo o trabalho e foi com grande alegria que verificmos durante os testes que de facto funcionava.

4.4 Falha de um cliente (farmcia)

4.4.1 Detetada ao pesquisar (ao interrogar servidor sobre famlia) Nesta situao a falha detetada pelo servidor. Um servidor, no mtodo informaSobreFamilia, pergunta a todas as farmcias se tm essa famlia (invoca mtodo temFamlia). Assim, se alguma farmcia estiver inoperacional, deteta-o. Em consequncia retira-a da sua lista de farmcias e propaga a alterao. Informa tambm o cliente para que este possa retir-la da lista de farmcias conhecidas. 4.4.2 Detetada ao consultar produtos (ao inquirir produtos farmcia) Nesta situao a falha detetada no cliente e tratada no servidor. O cliente, ao tentar invocar o mtodo remoto informaSobreProdutos de um determinado StockManager, deteta a falha. Informa o servidor invocando o mtodo desactivaFarmacia. O servidor confirma se de facto o StockManager est inoperacional invocando o mtodo ping. Em caso afirmativo trata a falha do modo j descrito no ponto anterior. Quando se trata de um falso alarme o cliente informado de que o servidor conseguiu contactar o StockManager.

4.5 Integrao de um novo servidor

A integrao de um novo servidor no anel (leia-se: um servidor que no estava inicialmente no anel, no pertencendo lista inicial lida de um ficheiro de configurao) surgiu naturalmente na sequncia da implementao da integrao de um servidor reinicializado. Desde que pelo menos um dos servidores que constam da lista inicial esteja ativo, o novo servidor vai conseguir integrar-se no anel. importante realar que o uri dos servidores s usado no boot

de um servidor, sendo que da para a frente os servidores so contactados via proxy e no mais so usados os portos ou uris. Assim, qualquer servidor consegue integrar-se no anel e sair dinamicamente. Num dado momento, a lista atual de servidores pode no ter nada em comum com a lista inicial (salvo a situao que j referimos).

5 Outros aspetos de implementao

assumido que uma zona corresponde a um servidor e que uma farmcia pertence a determinada zona e tem um nmero que a identifica; A configurao do remoting feita atravs de ficheiros de configurao: cada servidor carrega um ficheiro de configurao especfico (configServidor[Zona]) e cada cliente tambm (configCliente[Zona]). Cada zona est associada a um uri de um servidor e os dois ficheiro (servidor e cliente) de determinada zona partilham o mesmo uri; A configurao inicial do anel de servidores definida no ficheiro XMLconfig, que deve estar presente na diretoria do executvel do servidor; este ficheiro define pares zona/uri; O stock de famlias e produtos de determinado cliente carregado do ficheiro stockmanager_c[n], onde n corresponde ao nmero de identificao do cliente; este ficheiro deve estar presente na diretoria do executvel do cliente; Na situao em que uma farmcia pergunta ao servidor que StockManagers tm uma determinada famlia, optmos por redirecionar a pergunta aos StockManagers, em vez de manter uma lista de famlias no servidor. Esta segunda opo levaria a menos trfego da rede, mas implicaria redundncia de informao e a consequente gesto; alm disso a informao que o servidor daria ao cliente poderia no estar atualizada. Assim, face pergunta de um cliente, o servidor invoca o mtodo temFamilia de todos os StockManagers que conhece; Sempre que necessrio passar um network pointer para um StockManager entre cliente e servidor, passado um ElemListaFarmacias que inclui meta-informao (zona e id) em lugar de apenas um proxy. Esta aproximao facilita a implementao de vrias funcionalidades; A falha de uma farmcia (de outra zona) enquanto um servidor est inoperacional tratada: o servidor, no boot, pede a lista de farmcias atualizada; Na aplicao cliente, o Form e StockManager comunicam atravs de uma fila FIFO: sempre que chamado remotamente um mtodo do StockManager, este adiciona uma string descritiva da atividade lista; por outro lado, o Form escuta a lista periodicamente, atravs de um Timer; deste modo garante-se que no se perdem mensagens e que, sem sobrecarregar demasiado a aplicao (o event-handler chamado a cada meio segundo), as mensagens so visualizadas em tempo til.

6 Outros aspetos conceptuais

6.1 Tratamento de excees
Sempre que chamado um mtodo remoto, so tratadas as possveis excees.

6.2 Tempos de vida dos objetos

O tempo de vida do servidor tem de ser infinito, pois no pode perder o estado entre chamadas. O tempo de vida do StockManager tambm faz sentido que seja infinito, pois tem de estar disponvel para responder a pedidos. A opo contrria implicaria voltar a carregar o XML a cada pedido (se entretanto a instncia tivesse sido eliminada), alm de o SM perder o seu id e zona. Isto no crtico, pois h apenas uma instncia de StockManager por cliente e no ocupa muita memria. Se os dados dos medicamentos fossem de grande dimenso poderia pensarse numa soluo com base de dados e um SM SingleCall.

6.3 Modos de ativao dos objetos

Da discusso do ponto anterior retira-se a concluso de que, quer o servidor, quer o StockManager, devem ser objetos Singleton.

6.4 Protocolos de comunicao

Uma vez que o sistema real tem objetos alojados em mquinas diferentes, o IPC est fora de questo. A aplicao utiliza o protocolo TCP. Este protocolo binrio e as mensagens so mais compactas do que no HTTP. No entanto, num cenrio em que as mquinas comuniquem atravs da Internet, seria de considerar usar o protocolo HTTP, pois o TCP implica manter uma comunicao ponto-a-ponto aberta e pode levar a problemas de comunicao devido s firewalls.

6.5 Controlo de concorrncia

No foi possvel, no tempo de que dispusemos para a elaborao do trabalho, implementar o tratamento da concorrncia de forma global e completa. Em certos casos recorremos a locks, mas esta soluo no resolve a gesto da concorrncia num sistema distribudo. No entanto, idealizmos uma soluo mais globalizante para a gesto da concorrncia no acesso a um recurso. A manuteno da consistncia do estado do anel de servidores poderia ser conseguida implementando o seguinte esquema:

7 Pontos fortes e fracos

O nosso sistema exibe algumas das caractersticas desejveis nos sistemas distribudos, tais como: Sistema aberto - A especificao e documentao das interfaces chave do domnio pblico Expansibilidade - Servidores podem entrar e sair livremente do anel Tratamento de falhas As falhas mais comuns, quer do servidor quer do cliente, so tratadas Transparncia: - Ao acesso O cliente acede do mesmo modo ao seu prprio StockManager ou ao de outra farmcia - localizao Excluindo o boot, o sistema funciona sem o servidor conhecer o endereo dos outros servidores ou as farmcias conhecerem o endereo das outras farmcias - s rplicas H mltiplas instncias do servidor, o que melhora o desempenho, embora as farmcias estejam parcialmente prisioneiras do servidor da sua zona - s falhas Quando um servidor falha, as farmcias que j se conhecem continuam a comunicar e os restantes servidores continuam a dar acesso aos StockManagers da zona afetada - expansibilidade O sistema expansvel sem alterao da sua estrutura nem dos algoritmos implementados Por outro lado, h aspetos importantes que no foram tratados: Controlo da concorrncia (consistncia) Transparncia ao desempenho Um servidor de zona pode ficar sobrecarregado Aspetos de valor acrescentado (como a segurana, por exemplo)

7.1 Aspetos a melhorar

A aplicao cumpre os requisitos descritos no enunciado. Devido a problemas de funcionamento do grupo foi necessrio racionalizar o tempo e no nos foi possvel estabilizar a soluo tanto quanto gostaramos. Alguns aspetos que consideramos no serem centrais resoluo do problema proposto no esto ainda implementados: - O pedido/tratamento de uma encomenda de medicamentos (seria semelhante consulta de produtos) - As zonas e os medicamentos possveis esto ainda hardcoded no cdigo fonte do cliente - A definio nos AppSettings de quais os ficheiros de configurao a utilizar - Verificao/racionalizao do uso dos locks - Testes exaustivos aplicao Em termos de futuro, para que a aplicao pudesse de facto funcionar em mquinas distintas seria fundamental trabalhar com uris completos, em lugar de portos como acontece no nosso prottipo.

8 Prottipo de demonstrao
Para testar a aplicao foram criados batch files para lanar os vrios servidores de zona. Na raiz da soluo encontra-se tambm um atalho para a aplicao cliente. O cliente poder indicar a zona em que se pretende registar.

Exemplo do funcionamento bsico da aplicao:

O funcionamento tpico do cliente este: 1. Indicar a zona e o nmero de cliente. Registar o cliente. (S esto criados ficheiros com os stocks de produtos para 4 clientes diferentes) 2. Indicar a famlia que se pretende pesquisar. Pesquisar. 3. Selecionar qual a farmcia da qual pretendemos obter informaes. Consultar produtos. (So listados os produtos da famlia indicada existentes na farmcia selecionada) A dado momento poder listar as farmcias j conhecidas do cliente. medida que forem efetuadas pesquisas, vo sendo adicionadas farmcias a esta lista. Nesta situao deve ter em ateno que as farmcias listadas no espao Farmacias no correspondem a nenhuma pesquisa e, portanto, no esto relacionadas com a famlia que est selecionada. Pode no entanto selecionar qualquer famlia e qualquer farmcia e consultar os seus produtos. No espao LOG registado um log das aes mais relevantes do cliente. No espao Stock visualizado o stock da farmcia respetiva. No espao STOCK MANAGER so listados os pedidos que o objeto Stock Manager vai recebendo. O servidor vai enviando mensagens de log para a consola. Para configurar a aplicao de um modo mais completo poder consultar ou alterar os ficheiros de configurao: Na pasta ServidorFarmacias\bin\Debug: o configServidor[zona] Define os parmetros remoting do servidor dessa zona, nomeadamente o porto o XMLconfig Contm pares zona/porto de todos os servidores possveis da configurao base do anel Na pasta ClienteFarmaciasWinForms\bin\Debug: o configCliente[zona] Define os parmetros remoting dos clientes de uma determinada zona o stockmanager_c[n] Registo XML do stock de produtos do cliente n