Nesta secção e seguintes, discute-se a realização do segundo protótipo da DAMS, base- ado no novo modelo proposto no capítulo anterior.
Para a realização do representante DAMS referido na secção 5.2, em cada máquina, são várias as possibilidades. Poder-se-á optar por um único processo que contém todas as entidades servidoras necessárias. Mas, dada a separação desejada entre serviços e destes em relação ao núcleo da DAMS, sendo as suas interacções baseadas apenas na infraestrutura de comunicação que identifica cada entidade, é também possível implementar cada uma destas em termos de processos autónomos. Outras alternativas se colocam, que podem ser mais adequadas, dependendo de cada serviço, e da arquitectura interna pretendida para cada serviço. Algumas alternativas que se podem considerar como exemplos:
um único fluxo de execução — um único processo que suporta a implementação do núcleo DAMS em cada nó bem como todos os servidores dos serviços suportados nesse nó. Como consequência, cada máquina dispõe de um sistema centralizado, onde os vários pedidos serão atendidos, sequencialmente. Esta organização tem a limitação de só se atender um pedido de cada vez, mesmo quando estes sejam destinados a serviços distintos. Esta situação é tanto mais grave quanto mais demorado for o atendimento da cada operação, aumentando este com o aumento na taxa de pedidos que lhe chega. Este problema pode comprometer o objectivo dos canais de eventos, já que o próprio servidor do núcleo, tal como os outros servidores, vai estar sujeito ao atendimento sequencial para a recepção de novos eventos e sua propagação. Por outro lado, fica simplificada a gestão de acessos concorrentes ao estado do serviço ou da aplicação monitorizada.
um fluxo de execução próprio a cada serviço — múltiplos fluxos de execução (implemen- tados por threads ou por vários processos), onde cada um suporta um serviço. Permite concorrência entre os pedidos dirigidos a serviços diferentes assim como ao núcleo do sistema, garantindo que um pedido a um serviço, não bloqueia os pedidos para os restantes serviços. Continua a existir o problema no caso de pedidos simultâneos di- rigidos ao mesmo servidor, mas continuam a evitar-se os problemas de concorrência dentro do serviço, já que só é atendido um pedido em cada instante. O atendimento de pedidos de operações por um serviço, mesmo demoradas, já não vai interferir com
5.4. O segundo protótipo da DAMS 115
os outros serviços nem com o núcleo DAMS. Pode exigir suporte da plataforma sub- jacente para a criação dos vários fluxos de execução, o que não é previsto pelo modelo da DAMS, e dependerá assim da sua implementação, em cada caso.
um fluxo de execução próprio a cada pedido — para cada pedido recebido, é criado dinâ- micamente um novo thread (ou processo) para o atender, permitindo o atendimento de múltiplos pedidos simultâneos. Esta abordagem exige que cada serviço faça a gestão dos múltiplos fluxos em execução, podendo criar problemas com a partilha do estado do serviço e/ou da aplicação monitorizada, quando os vários fluxos lhes pretendem aceder. Neste caso, cada serviço tem de implementar, de acordo com as suas carac- terísticas e requisitos pretendidos, a gestão desses múltiplos fluxos e acesso aos seus recursos. Exige-se também suporte, por parte da plataforma, para a criação dos vários fluxos de execução e sua gestão, ficando para tal dependente da plataforma subjacente.
O modelo da arquitectura da DAMS permite qualquer abordagem para a realização de cada serviço, dado que a sua organização interna não está à partida definida, e se encontra escondida na API cliente. Na sua realização, a componente servidora é uma entidade que expõe apenas a sua interface, sendo a respectiva implementação transparente para a com- ponente cliente. Na abordagem de um único processo, antes referida, a interface de cada serviço é acrescentada à interface oferecida pelo processo representante da DAMS, mas é garantida a separação do espaço de nomes e mantém-se o registo e identificação autónomos de cada serviço. A abordagem de um fluxo de execução por pedido, introduz uma complexi- dade na sua implementação, que pode não compensar o que se pretende ganhar na resposta aos pedidos simultâneos, mas pode ser conveniente para alguns serviços. A implementação de cada serviço definirá a sua organização interna e a gestão que faz dos vários fluxos e do acesso a recursos partilhados, de acordo com as suas necessidades.
É também possível a realização de sistemas com soluções mistas, onde cada serviço adopta a organização que melhor se adequa aos seus objectivos. Enquanto certos serviços implementam o respectivo servidor no mesmo processo que o do núcleo DAMS, outros ser- viços podem optar por dispor de servidores em processos dedicados, ou recorrer à plataforma de suporte para a criação dinâmica de múltiplos threads.
Nas organizações com um único fluxo de execução, os problemas de bloqueio do pedido enquanto um pedido é atendido, podem ser contornados na concepção do próprio serviço. Há que evitar pedidos passíveis de bloquear o servidor por longos períodos, o que poderá
ser conseguido por um protocolo entre API cliente e o respectivo servidor, onde a verdadeira resposta é diferida, sendo utilizado o mecanismo de eventos para permitir notificar o cliente, quando a resposta fica disponível.
No protótipo desenvolvido para o novo modelo da DAMS, existe um único processo em cada nó, o qual inclui a implementação do próprio núcleo DAMS, junto com os servidores que realizam os serviços. Este processo funciona como o representante da DAMS nesse nó, suportando todas as funcionalidades, e podendo as ferramentas executar em qualquer das máquinas no sistema DAMS. A razão da opção tomada prende-se com a simplicidade do desenvolvimento, de modo a permitir a experimentação das funcionalidades do modelo, face a diferentes cenários de utilização.
5.4.1
Interface com o ORBit
Dada a opção de se recorrer a uma implementação da norma Corba como plataforma de suporte à comunicação, no caso o ORBit, dispomos da possibilidade de especificar as interacções entre as várias entidades na linguagem IDL do modelo Corba, gerando depois as funções de interface para cliente (stubs) e para o servidor do serviço (skels). As primeiras são utilizadas pela implementação da API de interface no lado do cliente. As segundas, por sua vez, são ligadas respectivamente, às funções que implementam o serviço no lado servidor, quando este é criado junto do núcleo DAMS.
A organização destes níveis pode ser traduzida segundo a figura 5.4, onde se representa a situação de uma ferramenta cliente, de um serviço e do núcleo DAMS. As interacções são realizadas com base nos vários níveis de abstracção, onde os superiores se baseiam exclusi- vamente nas funcionalidades dos imediatamente inferiores.
000 000 000 111 111 111 00 00 00 11 11 11 00 00 00 11 11 11 00 00 00 11 11 11 00 00 00 11 11 11 stubs
cliente imp. serv. imp.núcleo
skel. stub skel. dams−low
infr. CORBA SO interfaces:
API cliente de serviço API cliente do núcleo interface com plataforma