Arquitetura HealthDB
A "camada de persistência" está presente em todo e qualquer Sistema de Informação em Saúde (SIS). O HealthDB é uma proposta que visa "eliminar" o esforço de desenvolvimento dessa camada (problema), em particular, no que diz respeito a informações clínicas modeladas por meio de arquétipos (requisitos). Ou seja, além de reduzir os custos de desenvolvimento, essa proposta prepara o SIS em questão para a interoperabilidade semântica. Dito isso, a arquitetura de software visa definir como isso pode ser obtido.
- Documentação da Arquitetura de Software do HealthDB (considerar padrões aplicáveis).
- Desenvolvimento de prova de conceito por meio da qual a arquitetura possa ser investigada além de análise "estática" e, possivelmente, orientar iniciativas posteriores.
A arquitetura do HealthDB está organizada em visões:
- Client Software. Software que faz uso dos recursos do HealthDB. É o principal ator cuja interação típica pode ser modelada pelo envio de consultas (AQL) e recuperação dos resultados (ResultSet) por meio do uso de HealthDB API.
- DBA/Developer. Indivíduo que mantém o HealthDB em funcionamento (requisita funções de administração do HealthDB), além de requisitar serviços típicos durante o desenvolvimento, como a execução de consultas AQL.
As camadas do HealthDB são indicadas na figura abaixo. Os usos permitidos são exclusivamente entre camadas adjacentes (layer bridging not allowed) e de cima para baixo. A visão detalhada de cada uma das camadas identifica as responsabilidades de cada camada e os módulos aos quais tais responsabilidades estão atribuídas.
Os módulos de cada uma das camadas são identificados abaixo.
Os módulos da User Interface Layer são exibidos na figura abaixo. Cinco módulos implementam a interface HealthDB API, empregando linguagens distintas. O módulo Client Console que oferece acesso às funções administrativas, inclusive consultas, do HealthDB e o módulo com conjunto de funções similar, mas acessado via browser.
Detalhes de alguns módulos:
- Cliente Administrativo (CAD). Meio de acesso de usuários humanos às funções oferecidas pelo HealthDB, por exemplo, criação de contas e monitoramento, além da execução de consultas. Há previsão de implementação do CAD em duas versões: (a) gráfica e (b) console.
- HealthDB API. Clientes (softwares) interagem com o HealthDB trocando mensagens por meio dessa API. Convém destacar que toda informação que trafega para/do HealthDB faz uso dessa API.
Os módulos da Application Layer são apresentados no diagrama abaixo.
Detalhes:
- HealthDB Endpoint. Implementação do lado "servidor" da HealthDB API.
- Autenticação e Autorização (A2).
- Auditoria.
- Conexão com serviços externos utilizados pelo HealthDB, por exemplo, CNS, CNES e outros.
- Work Manager. Decide se o processamento de uma requisição deve ser iniciada imediatamente ou aguardar até que recursos considerados necessários estejam disponíveis para serem alocados à requisição. Adicionalmente, estabelece a ligação entre worker thread usada para tratar a requisição (lógico) e a correspondente implementação (física) usando threads em Java, lightweight thread, um processo ou outro mecanismo, inclusive o uso de pool desses recursos físicos.
- Use Case Manager. O HealthDB apresenta aos clientes alguns casos de uso: importar, exportar dados, acréscimo de arquétipo e, talvez o mais comum, consulta AQL.
- Session Manager. Responsável por manter o estado da conexão de um cliente com o HealthDB.
- Conversores. Assegura representação do formato empregado pelo HealthDB em XML, JSON e outros, e vice-versa.
Os módulos da Data layer são apresentados na figura abaixo.
Detalhes:
- ADL Compiler. Responsável por receber um arquétipo descrito em ADL e produzir a representação interna correspondente.
- AQL Compiler. Responsável por produzir a representação interna correspondente a uma consulta.
- Schema Generator (DSG). Módulo que recebe a representação interna de um arquétipo produzida pelo compilador de ADL e produz: (a) um esquema em conformidade com a storage engine a ser utilizada pelo HealthDB e (b) metadados correspondentes.
- Execution Plan Generator (DQG). Responsável por converter a representação interna de uma consulta, em conformidade com a representação interna do esquema (metadados) em consulta que pode ser executada pela storage engine.
- Storage Engine Conector. Conexão com a storage engine usada. Esse é o componente que, de fato, repassa para o storage manager requisições. No sentido inverso, o conector faz uso de um conversor dos dados produzidos pela execução do storage engine no formato empregado internamente pelo HealthDB.
- Metadata Manager. Oferece serviços para persistência de informações sobre dados.
- Keyword Processor. Módulo que produz, a partir de um conjunto de palavras-chave, uma consulta AQL correspondente.
- Adaptador. Realiza várias funções que permitem "isolar" uma implementação específica dos serviços de armazenamento da camada de dados.
- Native. Implementação personalizada para contemplar apenas os requisitos do HealthDB, por exemplo, não inclui a noção de transação. Inclui file manager, buffer manager e componentes similares. O Codec é um dos principais componentes, responsável pela representação dos dados no formato do HealthDB, assim como o Adapter, responsável pelo processo de empacotamento do resultado de consultas.
- SQL. Representa um SGBD relacional. Esse componente é externo ao HealthDB e, caso empregado, demanda implementação de Adaptador específico.
- NoSQL. Representa um SGBD NoSQL. Esse componente é externo ao HealthDB. Caso seja empregado, demanda implementação de Adaptador específico.
Embora não exibida nas figuras acima, a camada de infraestrutura oferece serviços comuns a mais de uma das camadas acima.
- File Manager. Encapsula serviço de acesso a arquivos. Implementação usando Hadoop HDFS deve ser fornecida.
- RingBuffer. Encapsula serviço de controle de acesso à memória compartilhada.
- Logging. Mantém registro de informações relevantes geradas durante a execução do HealthDB.
- Log Service. Serviço responsável por registrar em meio persistente as informações fornecidas no logging.
- Task Manager. Gerência das várias tarefas executadas concorrentemente pelo HealthDB.
- Config. Fornece valores empregados para orientar o comportamento do HealthDB em tempo de execução.
Os componentes do HealthDB podem ser executados, todos eles, em um único nó (computador), ou distribuídos em várias tiers: (a) client tier; (b) server tier e (c) back end tier, conforme ilustrado abaixo. Observe que os componentes em execução em cada uma das tiers são omitidos nessa figura.
- Documentação da arquitetura (Documenting Architecture Decisions) (exemplos)
- Transação
- Transação key/value
- Livros clássicos de SGBD possuem apresentação, breve, mas explícita para documentar a arquitetura de software.
- Architecture of a Database System
- Comentários sobre texto acima.
- Layered architecture base para as camadas acima.
- Evaluating Model-Driven Development for large-scale EHRs through the openEHR approach
- Evaluation of software maintainability with openEHR – a comparison of architectures
- Evolutionary architecture aplica-se nesse caso?
- Calcite oferece uma organização que pode ser empregada de forma semelhante para AQL.
- ServiceLoader é uma alternativa para OSGi, caso interfaces sejam definidas e implementações de módulos dominem aspectos da arquitetura, o que parece razoável, tendo em vista a possibilidade da participação de estudantes com implementações distintas.
- Modelo de arquitetura.
- Patterns of Modular Architecture