Vis˜ao f´ısica

O ponto de vista oferecido pela descri¸c˜ao da arquitetura f´ısica de um sistema eviden- cia aspectos de distribui¸c˜ao dos m´odulos em tempo de execu¸c˜ao. Uma das formas de se representar essa estrutura ´e utilizando diagramas UML de distribui¸c˜ao (deployment).

Esse tipo de diagrama ´e tipicamente composto por n´os ( ), componentes ( ), link de

comunica¸c˜ao (liga¸c˜ao entre n´os), interfaces ( ) e dependˆencias (entre componentes).

´

E usual tamb´em ilustrar instˆancias de n´os e componentes, no lugar de utilizar elementos abstratos, quantificando os poss´ıveis participantes.

A Figura 4.4 ´e um diagrama de distribui¸c˜ao para a aquitetura proposta neste trabalho. N˜ao s˜ao usadas interfaces de componentes e suas dependˆencias para n˜ao sobrecarregar a figura. Os n´os ilustrados s˜ao: ferramenta de cria¸c˜ao de documentos; ferramenta de gerenciamento; servi¸co gerenciador de documentos; servi¸co de ontologias; servidor Web; e duas instˆancias de servi¸co gerenciador de workflows.

As ferramentas de cria¸c˜ao de documento e de gerenciamento s˜ao clientes do servi¸co gerenciador de documentos, usando Java RMI como protocolo para comunica¸c˜ao em uma conex˜ao na Internet (TCP/IP). Al´em disso, a ferramenta de gerenciamento tamb´em pode ser cliente dos servi¸cos gerenciadores de workflows usando mensagens SOAP na Internet. O servi¸co gerenciador de documentos ´e cliente do servi¸co de ontologias, para consultar referˆencias a ontologias e recuperando partes de ontologias para realizar anota¸c˜oes em workflows, usando protocolo http na Internet. O servidor Web funciona como cliente do servi¸co gerenciador de documentos para recuperar documentos e dados relacionados. Entretanto, o papel principal do servidor Web ´e o de servir p´aginas dinˆamicas para clientes usando navegadores Web (n˜ao ilustrados na figura). O servi¸co gerenciador de documentos aparece como cliente dos servi¸cos gerenciadores de workflows, pedindo a execu¸c˜ao de um determinado workflow a um desses servi¸cos. Para executar um workflow, um gerenciador de workflows pode receber os dados juntamente com os pedidos ou fazer uso de dados dispon´ıveis na Web atrav´es de URIs.

O elemento central do sistema ´e o servi¸co gerenciador de documentos. Esse servi¸co engloba um banco de dados de documentos e referˆencias a dados gen´ericos para alimentar esses documentos (n˜ao necessariamente armazenados no banco de dados). O sistema operacional sobre o qual os elementos servidores ser˜ao executados ´e GNU/Linux. O SGBD utilizado ´e o PostgreSQL ([Pos]) e o servidor de aplica¸c˜oes (respons´avel pelas interfaces de servi¸cos Web) utiliza JBoss e Tomcat ([JBo, Apa]). As funcionalidades de registro RMI do JBoss tamb´em ser˜ao aproveitadas. Para cada instˆancia de servi¸co gerenciador de documentos, h´a exatamente uma instˆancia de um servidor Web e no m´aximo uma instˆancia ativa de ferramenta de gerenciamento. V´arias instˆancias de ferramentas de cria¸c˜ao, de servi¸cos de ontologias e de servi¸cos gerenciadores de workflows podem ser utilizadas simultaneamente com um mesmo gerenciador de documentos.

A ferramenta de cria¸c˜ao de documentos ´e composta por um m´odulo de interface gr´afica com o usu´ario, um conversor XML e um comunicador RMI. Os documentos criados pelo usu´ario s˜ao convertidos em uma representa¸c˜ao XML e s˜ao transmitidos ao servi¸co ge- renciador de documentos usando RMI. O caminho inverso para importar documentos

tamb´em ´e v´alido. A ferramenta de cria¸c˜ao tamb´em permite gravar/abrir c´opias locais dos documentos em arquivos XML. A ferramenta permite ainda solicitar a execu¸c˜ao de um determinado workflow ao gerenciador de documentos que, por sua vez, escolher´a o gerenciador de workflows mais adequado para realizar a execu¸c˜ao.

A ferramenta de gerenciamento utiliza duas interfaces de comunica¸c˜ao: RMI e SOAP. A primeira ´e utilizada na comunica¸c˜ao com o gerenciador de documentos, para realizar configura¸c˜oes do servi¸co e editar documentos espec´ıficos. A segunda trata das intera¸c˜oes com os servi¸cos gerenciadores de workflows, lidando com aspectos de controle de execu¸c˜ao. A ferramenta de gerenciamento permite iniciar a execu¸c˜ao de um workflow, visualizar e interferir nas execu¸c˜oes.

O servi¸co de ontologias utiliza o sistema OntoCover ([Fil03]) desenvolvido no Labo- rat´orio de Sistemas de Informa¸c˜ao da UNICAMP para fazer acesso a ontologias. O acesso pode ser feito atrav´es de URIs com referˆencias a p´aginas dinˆamicas. Com isso pode-se

validar uma cobertura ontol´ogica ([FLP+

03]), obter uma ontologia (ou partes dela) ou atualizar ontologias. As p´aginas dinˆamicas s˜ao suportadas pelo Tomcat e a execu¸c˜ao de opera¸c˜oes sobre as ontologias usa componentes Java (EJB).

O servidor Web utiliza p´aginas dinˆamicas para oferecer ao usu´ario, utilizando um navegador Web, visualiza¸c˜oes dos documentos e dos dados relacionados a eles. Pode-se, por exemplo, visualizar um workflow (imagem est´atica, sem possibilidades de edi¸c˜ao) e sua descri¸c˜ao, pedir a execu¸c˜ao desse workflow e visualizar os resultados obtidos (caso o tipo de dados gerado seja suportado). Para isso, o servidor faz uma chamada RMI, acessa o banco de dados e o sistema de arquivos compartilhado do servi¸co gerenciador de documentos, e se encarrega de construir as p´aginas dinamicamente, utilizando o Tomcat. O servi¸co gerenciador de workflows recebe pedidos de execu¸c˜ao de workflows especifi- cados em BPEL. Implementa um servidor de aplica¸c˜oes que utiliza JBoss e Tomcat para tratar das intera¸c˜oes e chamadas de execu¸c˜ao. O gerenciamento desse servi¸co pode ser feito por uma ou mais ferramentas de gerenciamento (no m´aximo uma por instˆancia de workflow).

Um ponto importante ´e a comunica¸c˜ao entre instˆancias de servi¸cos gerenciadores de do- cumentos. Isso possibilita o tratamento distribu´ıdo dos documentos, distribuindo a carga de uso do servi¸co. Apesar de ter a implementa¸c˜ao facilitada pela arquitetura proposta, aspectos de consistˆencia e concorrˆencia, por exemplo, limitam o uso desse mecanismo. Esse ´e, entretanto, um aspecto secund´ario neste trabalho.

Tem-se, assim, uma vis˜ao dos n´os computacionais presentes no modelo e suas res- ponsabilidades em tempo de execu¸c˜ao, juntamente com os sistemas respons´aveis por essa execu¸c˜ao. Alguns detalhes desses sistemas ser˜ao apresentados no Cap´ıtulo 5.