INTEROPERABILIDADE ENTRE APLICAÇÕES.NET

Transcrição

1 INTEROPERABILIDADE ENTRE APLICAÇÕES.NET Ricielli Pelissoli Martins Orientador: Luiz Gustavo Mählmann Universidade Luterana do Brasil (ULBRA) Sistemas de Informação Canoas RS Brasil Resumo. Este artigo apresenta como sistemas de informação presentes em diferentes ambientes computacionais podem comunicar-se entre si, compartilhando informações e criando um ambiente integrado de colaboração. Serão apresentadas no decorrer deste artigo as tecnologias e conhecimentos necessários que viabilizaram o projeto desenvolvido, assim como os sistemas desenvolvidos abordando o tema interoperabilidade entre aplicações. Palavras-chave: Interoperabilidade, Web, Windows, Mobile,.NET Framework, Web Service. 1. Introdução Este trabalho apresenta um estudo sobre as técnicas de interoperabilidade entre aplicações, mostrando as diferentes formas utilizadas na integração de sistemas de informação. Após a realização deste estudo, foi escolhida uma das técnicas apresentadas neste artigo para o desenvolvimento de um caso prático, com o intuito de embasar os conceitos apresentados. O case que faz parte deste projeto é o da empresa TOTVS S/A. Esta empresa possui um sistema de gestão hospitalar, chamado de PersonalMed Hospitalar. Hoje este sistema está disponível apenas em Intranet (rede local). A fim de comprovar os estudos realizados no decorrer deste trabalho foi desenvolvido um aplicativo Web que permite a manipulação da agenda de compromissos, recurso disponível no sistema PersonalMed Hospitalar, através da Internet. Este sistema poderá ser acessado de duas maneiras: na forma convencional, via Browser comum através de PC ou Notebook, ou poderá ser acessado também via dispositivo móvel. Quando o sistema é acessado via dispositivo móvel o mesmo modifica seu layout, provendo assim uma melhor navegação e utilização do sistema. A agenda existente no PersonalMed Hospitalar funciona basicamente como uma agenda comum. É através dela que são marcadas as consultas, cirurgias e exames que um paciente irá realizar com um médico. Este recurso, hoje disponível apenas no ambiente interno foi também disponibilizado no ambiente Web e Mobile, através do aplicativo Web desenvolvido. A ideia principal é possibilitar ao atendente a marcação de consultas e ao médico e ao paciente o acesso às informações sobre as consultas marcadas em qualquer lugar que estejam, e não apenas quando estão dentro do hospital. Ainda abordando o tema interoperabilidade entre aplicações, foi desenvolvido também, um agente para o ambiente Desktop que fica responsável por criar, no cliente de Microsoft Outlook existente na máquina do médico, compromissos de acordo com os agendamentos criados para ele e tarefas para cada consulta marcada, contendo informações sobre a consulta. Com o desenvolvimento dos sistemas anteriormente descritos fica garantida a interoperabilidade entre aplicações.net existentes em diferentes ambientes computacionais. A mesma informação gerada é compartilhada pelas diferentes aplicações. 1

2 Para embasar o projeto desenvolvido, foi realizada uma pesquisa sobre as tecnologias e conhecimentos necessários. Os próximos itens deste artigo abordam as tecnologias que serão utilizadas a fim de possibilitar que uma aplicação disponível em ambiente local seja integrada com aplicações disponíveis tanto em ambiente Web, Mobile, como também em ambiente Windows. 2. Referencial Teórico Com a evolução da tecnologia e das telecomunicações, permitindo o uso da Internet em alta velocidade, conjugada ao surgimento cada vez maior de dispositivos que possibilitam esse acesso, surge uma nova era da tecnologia da informação, onde a informação é disponibilizada em tempo real e em qualquer lugar. A diversidade de aplicações existentes, tecnologias, plataformas de desenvolvimentos, linguagens de programação e meios de comunicação é cada vez maior. Junto com esse avanço vem a necessidade de compartilhar estas informações. A tecnologia passou a ter que suportar um novo modelo de aplicações distribuídas em diferentes ambientes computacionais. Disponibilizar um ambiente integrado entre diferentes aplicações é mais que um diferencial nos dias atuais, é uma necessidade. Devido a esse avanço rápido e desordenado, aliado ao surgimento de novos e distintos meios de comunicação não existe hoje nenhum padrão que reja essa integração. Na medida em que foi surgindo a necessidade das aplicações se integrarem, as tecnologias foram evoluindo e criando ferramentas que possibilitassem essa integração. Hoje o que tem no cenário atual são sistemas distribuídos que conseguem se comunicar entre si de forma transparente ao usuário final, porém utilizando recursos e ferramentas que possibilitam esta integração. Chama-se esta integração entre sistemas de interoperabilidade entre aplicações e se dá de diferentes formas, de acordo com a tecnologia empregada. (INT, 2010) 2.1 Interoperabilidade Interoperabilidade é a capacidade de um sistema para interagir e comunicar com outro da forma mais transparente possível. O conceito parece bem simples, porém na prática o que se vê muitas vezes são desenvolvimentos bastante complexos a fim de possibilitar esta comunicação. (INT, 2010) Informações como o ambiente em que as aplicações estão inseridas, a plataforma, a linguagem de programação e os protocolos de comunicações são essenciais para se buscar a melhor técnica a ser empregada nesta integração Técnicas de interoperabilidade Existem hoje inúmeras técnicas de integração entre sistemas de informação (EAI, 2010). Foi realizado um estudo sobre as mais utilizadas, avaliando suas características, pontos positivos e negativos com o intuito de definir o padrão a ser seguido no desenvolvimento deste projeto File Transfer Integração entre aplicativos através da troca de arquivos em formato de texto definido. (FIL, 2010) 2

3 A troca de arquivos é o tradicional processo de exportar arquivos de um sistema e importar em outro. É uma forma de integração muito comum no processamento de lotes (batch), típicos dos mainframes. As principais dificuldades desse tipo de integração estão na definição do formato para os arquivos e na sincronização das informações existentes com as novas, depois de cada importação de dados. A disseminação do XML facilitou a definição dos formatos para a troca de arquivos, mas o problema de sincronização permanece difícil. Uma vantagem da integração por troca de arquivos é dispensar o software intermediário de integração, pois o sistema operacional já fornece quase toda a infra-estrutura necessária, requerendo talvez apenas um analisador para o formado escolhido, por exemplo, um parser XML. Muitas empresas ainda utilizam esse tipo de integração através de troca de arquivos. Sistemas com um legado muito grande ou pouco avanço tecnológico costumam utilizar esse tipo de solução, como se vê no padrão adotado pela ANS (Agência Nacional de Saúde) referente à Troca de Informações em Saúde Complementar, a chamada TISS. A ANS definiu algumas regras com o intuito de regulamentar as informações trocadas entre os prestadores de serviço de saúde (hospitais, clínicas, etc.) com as operadoras de planos de saúde (convênios). Ficou definido que estas informações serão trocadas através de arquivos XML. (TIS, 2010) Shared Database Figura 1 Integração de sistemas através de troca de dados via arquivo. Integração entre aplicativos através da troca de dados entre bases de dados ou tabelas. (SHA, 2010) Esta integração pode ocorrer através de gatilhos, por exemplo, ao gerar uma fatura no sistema A, automaticamente um gatilho é acionado enviando dados para o banco de dados do sistema B de forma transparente ao usuário, ou quando diferentes sistemas de informação compartilham a mesma base de dados, como mostra a Figura 2. Figura 2 Integração de sistemas através de troca de dados via database. Este tipo de integração possui ponto forte com relação à disponibilidade dos dados, ou seja, no momento em que várias aplicações compartilham a mesma base de dados estes dados, 3

4 ficam disponíveis para ambas as aplicações em tempo real e de forma consistente. Em contra partida caso o banco de dados fique indisponível todas as aplicações que compartilham este banco ficarão indisponíveis também. Outro ponto negativo para este tipo de técnica de integração entre sistemas é a manutenção do banco, uma vez que este é compartilhado por várias aplicações qualquer alteração na estrutura do banco existente deve ser bem planejada evitando assim gera problemas nas demais aplicações que compartilham a mesma base de dados Messaging Integração entre aplicativos de um middleware orientado a mensagem (MOM) o qual é responsável pela entrega dos dados aos sistemas integrados. Um middleware é um programa de computador responsável por mover ou transportar informações e dados entre programas de diferentes protocolos de comunicação, plataformas e dependências do sistema operacional. Seu objetivo é facilitar o desenvolvimento de aplicações, assim como facilitar a integração de sistemas legados ou desenvolvimentos de forma não integrada. (MES, 2010) Remote Procedure Call (RPC) Figura 3 Integração de sistemas através de mensagens. Define um protocolo para execução remota de processos entre computadores ligados em rede. O protocolo RPC pode ser implementado sobre diferentes protocolos de transporte. Não cabe ao RPC especificar como a mensagem é enviada de um processo para outro, mas somente especificá-la e interpretá-la. A sua implementação depende, portanto, sobre qual protocolo de transporte vai operar. (RPC, 2010) RPC é uma tecnologia popular para a implementação do modelo clienteservidor de computação distribuída. Uma chamada de procedimento remoto é iniciada pelo cliente enviando uma mensagem para um servidor remoto para executar um procedimento específico. Uma resposta é retornada ao cliente. Uma diferença importante entre chamadas de procedimento remotas e chamadas de procedimento locais é que, no primeiro caso, a chamada pode falhar por problemas da rede. Nesse caso, não há nem mesmo garantia de que o procedimento foi invocado. Existem algumas diferentes implementações para o modelo RPC que possuem características distintas e que variam de acordo com a plataforma empregada. 4

5 Figura 4 - Seqüência de passos de uma chamada remota de procedimento Remote Method Invocation (RMI) Arquitetura desenvolvida para a plataforma Java, introduzida no JDK versão 1.1 do Java. Foi desenvolvida com o intuito de permitir o desenvolvimento de aplicações Java para ambientes distribuídos. (GUJ, 2010) A arquitetura RMI é baseada em um importante princípio: a definição do comportamento e a implementação do comportamento são conceitos separados. RMI permite que o código que define o comportamento e o código que implementa o comportamento permanecerem separados e rodarem em JVMs separadas. Em RMI, a definição do serviço remoto é codificada usando uma interface Java. A implementação do serviço remoto é codificada em uma classe. Logo, a chave para se entender o RMI é lembrar que as interfaces definem o comportamento e as classes definem a implementação. A classe que implementa o comportamento roda do lado do servidor RMI. A classe que roda no cliente atua como um Proxy para o serviço remoto, como mostra na figura 5. (GUJ, 2010) Figura 5 Arquitetura RMI Distributed Component Object Model (DCOM) DCOM é uma tecnologia proprietária da Microsoft para a criação de componentes de software distribuídos em computadores interligados em rede. A tecnologia existente no Framework.NET substitui a antiga tecnologia COM. (DCO, 2010) 5

6 Figura 6 Arquitetura DCOM Common Object Request Broker Architecture (CORBA) Arquitetura padrão, criada pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software que encontra-se atualmente, CORBA atua de modo que os objetos (componentes de softwares) possam se comunicar de forma transparente ao usuário, mesmo que para isso seja necessário interoperar com outro software, em outro sistema operacional e em outra ferramenta de desenvolvimento. CORBA é um dos modelos mais populares de objetos distribuídos, juntamente com o DCOM, formato proprietário da Microsoft. (COR, 2010) O Object Management Group, ou OMG, é uma organização internacional que aprova padrões abertos para aplicações orientadas a objetos. Esse grupo define também a OMA (Object Management Architecture), um modelo padrão de objeto para ambientes distribuídos. O Object Management Group foi fundado em A especificação CORBA define uma estrutura de interfaces consistindo de três componentes específicos: interface do cliente, interface da implementação dos objetos e o núcleo ORB, como é mostrado na Figura 7. Figura 7 Arquitetura de Interfaces CORBA Simple Object Access Protocol (SOAP) SOAP é um pacote de protocolo padronizado para as mensagens compartilhadas entre aplicações. O SOAP foi projetado para encapsular e transportar chamadas de RPC (Remote Procedure Call), e para isto utiliza-se dos recursos e flexibilidade do XML, sob HTTP. A 6

7 especificação define um modelo baseado em um envelope XML para que as informações sejam transformadas e um conjunto de regras para tradução de peculiaridades específicas de uma aplicação ou plataforma ou tipos de dados contidos na representação XML. (SOA, 2010) Figura 8 Constituição de uma mensagem SOAP Segundo a W3C (2010), para toda chamada RPC são necessárias as seguintes informações: A URI do objeto alvo; O nome do método; Os parâmetros do método (requisição ou resposta); Uma assinatura do método opcional; Um cabeçalho (header) opcional. O elemento Envelope especifica: Figura 9 Exemplo de um envelope de requisição RPC A URI identifica o namespace utilizado por esta requisição SOAP. possui o namespace padrão para todas as mensagens SOAP; O encodingstyle (estilo de codificação) é definido pela URI e identifica o estilo de codificação a ser utilizado. O cabeçalho Header define: Um atributo chamado Transaction que define um namespace (URI) para o elemento; O atributo mustunderstand=1 especifica que o cabeçalho deve ser processado pelo receptor da mensagem; 7

8 O valor 5, que deve ser um valor compreendido pelos serviços que processam esta mensagem. O elemento Body define: Uma chamada de método GetLastTradePrice e seu respectivo namespace; O elemento DIS especifica um parâmetro contido na chamada de método GetLastTradePrice. Além disto, o protocolo SOAP fornece a semântica para o envio e recebimento dos dados (XML), codificando os parâmetros de entrada/saída invocados pelas operações publicadas pelo Web Service. Em outras palavras, SOAP é uma aplicação especificada por XML. Isto garante uma intensa observância aos padrões XML como schema e namespaces para suas definições e funções. (SOA, 2010) Algumas das vantagens do protocolo SOAP encontram-se na sua simplicidade e, na facilidade de entendê-lo e implementá-lo. O SOAP comparado com as abordagens anteriores é significativamente menos complexo, facilitando assim a sua ampla aceitação por parte dos desenvolvedores de software. Mais alguns pontos significativos, é o fato de ele trabalhar com protocolos padrões de Web, como XML, HTTP e TCP/IP, e permitir que programas escritos em diferentes linguagens, em diferentes plataformas, se comuniquem de forma padronizada. A comunicação realizada pelos serviços de Web (Web Services) é realizada através de mensagens SOAP Web Service Figura 10 Tráfego de mensagens via XML Segundo Potts (2003), um Web Service é uma aplicação de software que pode ser acessada remotamente usando diferentes linguagens baseadas em XML. O Web Service é uma tecnologia emergente, sobre a qual muito se tem pesquisado. Alguns pesquisadores definem como o caminho a seguir no desenvolvimento de aplicações distribuídas, enquanto que outros vêem nelas apenas mais uma evolução de um conceito antigo. Sendo aplicações modulares, auto descritivas, acessíveis através de uma URL, independentes das plataformas de desenvolvimento e que permitem a interação entre aplicações sem intervenção humana, os Web Services apresentam-se como a solução para os atuais problemas de integração de aplicações distribuídas (LOP, 2004). Estas suas características devem-se em grande parte ao fato de se basearem em normas standard, entre as quais se destacam: XML, SOAP, WSDL e UDDI. Um Web Service é semelhante na medida em que é acessado através de uma URL. A diferença está no conteúdo do que é enviado na requisição do cliente para o servidor. Os clientes de Web Service enviam um documento XML, formatado de uma maneira especial, de acordo com as regras da especificação SOAP. (W3C, 2010) 8

9 O ciclo de vida de um Web Service compreende quatro estados distintos, conforme a figura 11, são eles: Figura 11: Ciclo de Vida do Web Service Publicação Processo, opcional, através do qual o fornecedor do Web Service possa conhecer a existência do seu serviço, efetuando o registro do mesmo no repositório de Web Services (UDDI); Descoberta Processo, opcional, através do qual uma aplicação cliente toma conhecimento da existência do Web Service pretendido pesquisando num repositório UDDI; Descrição Processo pelo qual o Web Service expõem a sua API (documento WSDL). Desta maneira a aplicação cliente tem acesso a toda a interface do Web Service, onde se encontram descritas todas as funcionalidades por ele disponibilizadas, assim como os tipos de mensagens que permitem processar as rotinas; Invocação Processo pelo qual cliente e servidor interagem, através do envio de mensagens de entrada e de eventual recepção de mensagem de saída do Web Service. Fazendo com que os Web Services possam ser desenvolvidos e publicados para poderem ser utilizados por um processo de software. Os Web Services funcionam a partir de uma necessidade de Software. Que deverá possuir uma solicitação do Cliente, onde o Web Service estará executando as atividades necessárias para poder processar as informações e retornar em formato XML (W3C, 2010), conforme mostrado na Figura 12. Figura 12: Funcionamento do Web Service Porém, a tecnologia possui alguns pontos fracos. Segundo Potts (POT, 2003), alguns dos problemas inerentes a tecnologia são: Disponibilidade Nenhum sítio Web está 100% do tempo disponível, não é possível garantir esta disponibilidade. Como a tecnologia Web Service é baseada nos mesmos padrões que regem os sítios Web ele sofre do mesmo problema. Sistemas que necessitam desta disponibilidade como ponto forte da integração devem procurar outra solução. Devido a este problema o ideal é que se criem mecanismos que tentem repetir as transações ou que finalizem as mesmas de uma forma amigável. Interfaces imutáveis No investimento de criação de um Web Service para os clientes, deve ser evitada a mudança de qualquer um dos métodos que é fornecido e os parâmetros que os 9

10 clientes esperam. Podem-se criar novos métodos e acrescentá-los ao serviço, mas, se mudar os métodos existentes, os programas dos clientes falharão. Isso é fácil de fazer até que se descubra que um dos seus métodos existentes está retornando respostas erradas e não pode ser reparado porque a metodologia é fundamentalmente falha. Embora esse tipo de problema ocorra em todos os sistemas, isso é especialmente verdade nos Web Service. Pode-se não saber quem está usando o serviço e, conseqüentemente, não existe uma maneira de informar esses usuários da mudança. Garantia de execução O HTTP, protocolo sob o qual o Web Service é executado, não é um protocolo seguro, uma vez que não garante entrega ou resposta. Se for preciso esse tipo de garantia é necessário a implementação através de um agente intermediário. O conhecimento destes problemas é importante para o correto planejamento e desenvolvimento de acordo com as características da tecnologia Extensible Markup Language (XML) Extensible Markup Language (XML) é um formato de texto flexível derivado do Standard Generalized Markup Language (SGML) definida pela ISO Originalmente, foi concebido para a publicação eletrônica de informação em larga escala. Desempenha, também, um importante papel como padrão de comunicação de informações na Internet. (W3C, 2010) O projeto da construção da linguagem de marcação XML foi basicamente norteado pela necessidade de criação de uma linguagem que fosse integrada a qualquer tipo de software e/ou linguagem. O projeto subsidiou-se ainda, sobre os seguintes pilares: Separação do conteúdo da formatação; Simplicidade e Legibilidade, tanto para humanos quanto para computadores; Possibilidade de criação de tags sem limitação; Criação de arquivos para validação de estrutura; Interligação de bancos de dados distintos; Concentração na estrutura da informação, não em na sua aparência. Além disto, existem algumas diretivas a serem observadas para utilização da tecnologia XML, são estas: (W3C, 2010) XML deve ser diretamente utilizado sobre a Internet; XML deve suportar uma grande variedade de aplicativos; XML deve ser compatível com SGML; Deve haver facilidade em escrever programas aos quais sejam processados documentos XML; A quantidade de características opcionais no XML deve ser evitada ao máximo, sendo recomendado não existirem; Documentos XML devem ser inteligíveis e razoavelmente limpos; O projeto do XML deve ser construído rapidamente; O projeto do XML deve ser formal e conciso; Os documentos XML devem ser fáceis de serem criados; Aparência na marcação XML é a coisa menos importante. 10

11 Documentos XML O objeto da construção de um texto de marcação com a utilização de XML é o documento. Cada documento XML possui uma estrutura definida: Lógica O documento é composto por declarações, elementos, comentários, caracteres, referência e instruções de processo indicadas explicitamente no documento; Física O documento é composto por unidades chamadas entidades. Uma entidade pode fazer referência à outra para incluí-la a um documento. Entretanto um bloco de texto só é reconhecido como um documento XML caso seja bem formado. Além disto, o documento XML é válido se este observa determinadas restrições. (W3C, 2010) Neste sentido, um documento é considerado bem formado se observar, em sua produção, conforme ilustra a Figura 13, os seguintes aspectos: Possuir uma declaração inicial (que pode ser vazia); Deve possuir um elemento Root (que pode conter n elementos); Opcionalmente pode possuir uma parte mista (comentários, instruções de processamento, etc.); Todos os elementos devem ter anotações de início e fim; Os elementos devem ser aninhados corretamente, ou seja, o fechamento de um elemento deve corresponder ao elemento imediatamente anterior de nome afim. 2.2 Programação Multiplataforma Figura 13: Documento XML bem formado Chama-se de multiplataforma um programa ou sistema que é executado em mais de uma plataforma. Tecnologias como Java, por exemplo, possibilitam o desenvolvimento de sistemas que podem ser executados em diferentes sistemas operacionais. Outra característica interessante do Java é a possibilidade de desenvolver sistemas que exijam baixo recurso de hardware, sendo por esse motivo, uma das principais opções no desenvolvimento de sistemas para dispositivos como celulares. Em contra partida ao desenvolvimento Java vem a plataforma.net da Microsoft, destinada a plataforma Windows, onde não existe a programação multiplataforma. Porém, a plataforma.net possui outras vantagens que a plataforma Java não possui, como, por exemplo o desenvolvimento de sistemas utilizando diferentes linguagens de programação. 11

12 O Framework.NET da Microsoft, objeto de pesquisa e estudo deste projeto, disponibiliza uma série de ferramentas e recursos com a intenção de auxiliar os desenvolvedores que, além do desenvolvimento de sistemas, buscam integrar sistemas de informação desenvolvidos nesta plataforma. Através da IDE de desenvolvimento da Microsoft, programadores de diferentes aplicações.net podem compartilhar o desenvolvimento com o que chama-se de reaproveitamento de código, ou seja, aplicações Web, Windows ou Mobile são desenvolvidas de forma homogênia, podendo assim estas diferentes aplicações se apropriarem dos mesmos códigos-fonte. IDE é um ambiente integrado de desenvolvimento que reúne características e ferramentas de apoio ao desenvolvimento de software. A escolha de qual caminho seguir, programação multiplataforma ou não, dependerá muito da estratégia adotada. No caso deste projeto, foi escolhida a solução Framework.NET da Microsoft pois o sistema PersonalMed Hospitalar é desenvolvido nesta plataforma e a integração com o ambiente desktop se dará através do cliente de Microsoft Outlook, solução da Microsoft. Além das vantagens citadas anteriormente NET Framework Segundo documentação da Microsoft, o.net Framework é um componente integrado ao Windows que suporta a execução e o desenvolvimento de aplicações e Web Service XML. Consiste em um ambiente consistente de programação orientado a objetos de modo que o código do objeto é armazenado e executado localmente, mas pode ser também armazenado na Internet e executado remotamente. (VGC, 2010) O.NET Framework da Microsoft proporcionará os recursos necessários permitindo o desenvolvimento de um aplicativo Windows e um aplicativo Windows Mobile que se integrarão a um sistema Web. Os itens a seguir descrevem os principais componentes presentes no.net Framework. Compilação Aplicação Visual Studio.NET CLR MSIL Execução MSIL CLR Sistema Operacional Figura 14: Esquema de Compilação e Execução 3. Requisitos para Implementação do Caso Prático Foram levantados os requisitos necessários para a implementação do caso prático proposto neste projeto, que tem como objetivo aplicar uma das técnicas de interoperabilidade entre aplicações, mostrando assim o seu funcionamento. 12

13 3.1 Levantamento de Requisitos Fez-se necessário o desenvolvimento de uma aplicação Web que será usada com o intuito de criar um ambiente integrado entre aplicações. Na solução desenvolvida, a aplicação Web será integrada à aplicação PersonalMed Hospitalar podendo assim, realizar ações anteriormente disponíveis apenas no sistema Hospitalar. Outro requisito desenvolvido foi a aplicação para o ambiente Windows. Esta aplicação fica instalada na máquina do médico e através dela, o médico pode importar as informações de agendamentos disponíveis no sistema PersonalMed Hospitalar para o cliente de s Microsoft Outlook estando em qualquer lugar, tendo acesso a Internet. Para o desenvolvimento de ambas as aplicações foi necessário o uso de uma das técnicas de integração entre sistemas de informação apresentadas neste artigo, viabilizando assim, a interoperabilidade entre as aplicações que envolvem este caso prático Sistemas Existentes O sistema existente na empresa, conforme anteriormente mencionado, é um sistema de gestão hospitalar chamado de PersonalMed Hospitalar. O sistema atualmente é desenvolvido sob a plataforma de desenvolvimento Microsoft.NET Framework 3.5 e trabalha com os bancos de dados Oracle e Microsoft SQL Server. O sistema é capaz de automatizar todo o negócio hospitalar, desde o atendimento de urgência ao paciente, até controle de estoque, financeiro e gerência hospitalar. Seu desenvolvimento acompanhou a evolução da plataforma.net, tendo sua primeira versão lançada no Microsoft.NET Framework 1.1 beta. Ele trabalha com o componente Microsoft Reports Server para a geração de relatórios e possui algumas interações com componentes de terceiros visando a utilização de periféricos tais como impressoras fiscais, leitores de código de barras, entre outros. O sistema está presente em alguns dos principais hospitais do país como o Hospital do Coração de São Paulo e o Hospital referência da Unimed em Belo Horizonte. 3.2 Análise dos Requisitos A correta utilização de uma das técnicas de integração entre sistemas de informação pode ser apontada como fator crítico para o sucesso deste projeto, tendo em vista que esta será a responsável pela troca das informações entre as aplicações. 4. Solução Desenvolvida Após analisar as técnicas existentes de integração entre sistemas de informação e, levando em consideração que a empresa TOTVS S/A trabalha com soluções Microsoft, ficou definido que a integração entre os sistemas que envolvem este projeto seria viabilizada através de Web Service. As informações entre as diferentes aplicações serão compartilhadas através de trocas de mensagens XML, comportamento base para a comunicação entre aplicações através do uso de Web Service. Esta troca de informações utilizando arquivo XML possibilita a independência entre as aplicações, pois uma aplicação não precisa conhecer a linguagem da outra, mas sim saber interpretar arquivo XML. A escolha pelo Web Service como solução que permitirá esta integração deu-se ao fato de ser uma tecnologia presente na maioria das integrações entre 13

14 sistemas Web existentes, de fácil implementação, bastante confiável e segura. Além de ser a solução recomendada pela Microsoft para integração entre sistemas Web. Com base nessa necessidade, foi desenvolvido um Web Service, permitindo assim a troca de informações entre as aplicações. O Web Service foi integrado à aplicação PersonalMed Hospitalar e as aplicações Web e Windows serão consumidores deste serviço. 4.1 Interoperabilidade da Aplicação Será garantida a interoperabilidade entre as aplicações no momento em que as mesmas informações estiverem sendo compartilhadas entre diferentes ambientes computacionais. No cenário anterior a este projeto, as informações existentes no sistema PersonalMed Hospitalar, sobre os agendamentos realizados no hospital só estavam disponíveis através do próprio sistema. No novo cenário, estas informações estão disponíveis também em outros ambientes computacionais e mais que isso, estas informações podem ser manipuladas Aplicação PersonalMed Hospitalar O recurso existente na aplicação PersonalMed Hospitalar compartilhado pelos demais sistemas é a agenda de compromissos. Através desta agenda são marcadas consultas, realização de exames, cirurgias e demais serviços que o hospital disponibiliza e que necessitem de agendamento. Junto à aplicação Hospitalar foi integrado o Web Service que proverá a troca de informações entre as aplicações Diagrama de Caso de Uso O diagrama de casos de uso é um diagrama da UML cujo objetivo é representar um requisito do sistema que será automatizado. A Figura 15 representa os casos de uso do sistema Web, mostrando a interação dos diferentes atores com o sistema. Como é mostrado, o funcionário do Hospital pode consultar, realizar, alterar e cancelar agendamentos. Já os usuários que possuem perfil de médico e paciente podem apenas consultar os agendamentos marcados para seu usuário. No caso do médico ele poderá consultar a data de seus próximos atendimentos e no caso do paciente ele poderá consultar quando possui uma consulta marcada e com qual médico será esta consulta. Figura 15: Caso de Uso 14