Integração de Sistemas de Informação Universitários via Web Services

Transcrição

1 Integração de Sistemas de Informação Universitários via s Carlos Costa Serviços Académicos da Universidade dos Açores CMATI Universidade dos Açores ccosta@uac.pt Ana Cristina Melo Serviços Acção Social da Universidade dos Açores cmelo@uac.pt Abstract - O crescimento de uma instituição, tal como uma Universidade, em número de pessoas e espaço físico, tende a fragilizar a comunicação entre os seus colaboradores. Este factor pode comprometer o desempenho dos seus serviços, dificultando o fluxo dos processos administrativos com consequências financeiras e pedagógicas para a instituição. Neste artigo vamos apresentar o desenvolvimento de um protótipo de uma solução para a integração de vários sistemas de informação, através de s, num contexto universitário, particularmente heterogéneo e descentralizado, a Universidade dos Açores (U Aç). Com esta solução, pretendemos mostrar a adequação do desenvolvimento de sistemas de software baseados numa arquitectura orientada a serviços. A sua implementação, utilizando s, permite agilizar, de forma rápida, segura, escalável e económica, o importante intercâmbio de informação (crítica) entre unidades internas (e.g. Serviços Académicos e Serviços de Acção Social) e externas (e.g. companhia aérea regional, e Segurança Social) à U Aç. Keywords-component Sistemas de Informação; Integração de Sistemas; s. I. ESBOÇO DO PROBLEMA Estudos recentes indicam que a complexidade e a dimensão das tarefas exercidas diariamente numa instituição exigem maior cooperação e colaboração entre pessoas ou grupos de pessoas [4]. Um tipo de instituição que está, particularmente, exposta a rápidas transformações, a uma dinâmica própria de desenvolvimento e a um acelerado ritmo de crescimento é a Universidade. Tipicamente, é um contexto muito dividido em termos orgânicos onde algumas das suas unidades possuem autonomia alargada dentro da instituição. E, assim, na UAç, em consequência da intensa produção e consumo de informação, particularmente significativa nas vertentes académica e financeira, cada unidade foi desenvolvendo o seu sistema de informação, criando um sistema de informação muito heterogéneo, descentralizado e desintegrado. Portanto, é um contexto interessante para estudar o impacto da implementação Aníbal Fernandes Secretaria Regional de Educação e Formação Anibal.MC.Fernandes@azores.gov.pt Luís Mendes Gomes, Hélia Guerra CMATI Universidade dos Açores lmg@uac.pt, helia@uac.pt de novas abordagens associadas à integração de sistemas de informação. Vamos centrar a nossa atenção numa solução de integração dos Serviços Académicos (SA) e dos Serviços de Acção Social (SASUA), porque são os maiores produtores de informação na UAç e nos quais assentam muitas das suas decisões estratégicas e financeiras. Esta informação está relacionada com: os alunos candidatos a benefícios sociais, para o cálculo da propina e para o desconto sobre os emolumentos; o aproveitamento escolar dos candidatos a benefícios sociais para a atribuição de bolsa e informação dos beneficiários que não pagam as propinas e o seu regime de estudo; o desconto de estudante nas viagens efectuadas em tempo de aulas. O sistema de informação dos SA é constituído por um sistema de gestão de bases de dados Oracl e por um conjunto de aplicações backoffice. Estas são responsáveis pela gestão, tratamento, transporte e divulgação da informação dos serviços que abrange, entre outros, os planos curriculares, os dados pessoais e curriculares dos alunos, a distribuição de serviço docente, os horários e gestão de salas de aula, a gestão de pautas e classificações e a gestão de propinas e emolumentos. O sistema de informação dos SASUA, no que diz respeito às bolsas de estudo, é constituído por um sistema de base de dados MS SQL Server e por uma aplicação backoffice que é responsável pela gestão de candidaturas a benefícios sociais, cálculo, atribuição, processamento e controle de validações. 290 CISTI 200

2 Figura Troca de informação entre SA e SASUA. Actualmente, como podemos observar na Fig., os sistemas de informação dos SA e SASUA não comunicam entre si. Os colaboradores dos serviços recorrem ao correio electrónico, fax, telefone ou correspondência interna para a troca de informação. Mais, a comunicação com entidades externas à UAç, nomeadamente a Companhia aérea local (CA) e o Instituto de Acção Social (IAS), é estabelecida recorrendo aos mesmos meios. O atraso nesta troca de informação causa atrasos na atribuição das bolsas de estudo, erros no pagamento de emolumentos e propinas e problemas na atribuição do desconto de estudante na tarifa aérea. Este último aspecto é, particularmente, relevante pelo facto da UAç se situar num arquipélago onde o único meio de transporte eficaz é o aéreo. Assim, é fácil perceber que uma ferramenta que auxilie e ofereça uma consulta de informação entre os colaboradores, para a obtenção e construção de conhecimento (organização inteligente), pode beneficiar muito as entidades envolvidas, melhorando o serviço prestado aos seus utentes. II. DISCUSSÃO DE UMA SOLUÇÃO Uma solução apresentada pela empresa que desenvolve o sistema de informação dos SA propôs a centralização dos sistemas numa única plataforma mas, no entanto, esta solução nunca foi implementada Neste artigo, propomos uma solução baseada em Web Services (WS) pelo facto de ser possível a adaptação do software a mudanças de negócio e necessidades dos clientes. Em vez de se integrar e codificar processos de negócio que resultam em aplicações que requerem desenvolvimento dispendioso e moroso, resultando em manutenção complexa. Esta solução baseada em WS tem as seguintes vantagens [3]: é independente da plataforma e da linguagem de programação; suporta protocolos Web (e.g. SOAP); é flexível, escalável e reutilizável; permite reduzir custos, automatizando a interacção entre aplicações e processos de negócio; permite reduzir custos de transacção. A integração dos sistemas de informação que propomos assenta numa arquitectura orientada a serviços [2], que dá suporte a dois sistemas de gestão de bases de dados Oracle e MS SQL Server, de forma a que: a integração da informação e comunicação seja estabelecida por WS; os WS desenvolvidos permitam fornecer um conjunto de serviços; os WS incluam um módulo de gestão de utilizadores indexados a um perfil de acesso; as aplicações Cliente sejam desenvolvidas com interface gráfica para o utilizador aceder aos serviços disponíveis, de acordo com um determinado perfil. Estes WS permitem a qualquer aplicação, que suporte o protocolo SOAP, utilizar os seus serviços que classificamos por: Internos: consulta de dados académicos, consulta de dados sobre propinas, consulta de dados sobre aproveitamento, consulta de dados sobre as candidaturas a benefícios sociais e consulta de dados sobre o regime de frequência; Externos: consulta de dados para desconto na passagem aérea, destinado à companhia aérea e às agências de viagens e consulta de dados para a segurança social, destinado aos Serviços de Segurança Social. O objectivo é disponibilizar informação precisa e atempada, de forma a minimizar os problemas provenientes da latência na partilha de informação que se encontra distribuída e desintegrada. Para que a sua consulta seja efectuada on-line, através de um browser, em que o Cliente possa requisitar uma página Web ou um documento (e.g. em XML) com a informação pretendida. Este documento poderá ser utilizado para a integração e actualização dos dados no sistema de informação do Cliente. III. REQUISITOS Nesta secção, vamos fazer o levantamento dos requisitos para o sistema de gestão académica UAç, recorrendo a diagramas de case de uso UML []. Gestão académica UAç Serviços Externos requisição Serviços Internos Gestão de utilizadores Cliente resposta Dados Figura 2 Sistema Gestão académica UAç. Como podemos observar na Fig. 2, o sistema de gestão académica UAç é composto por: Serviços Externos: disponibilizam serviços a entidades externas à UAç; Serviços Internos: disponibilizam serviços a outras unidades internas da UAç; Gestão de Utilizadores: subsistema para gerir o acesso dos utilizadores que dividimos nas 3 categorias seguintes, em função do acesso à informação: CISTI

3 ! Base: utilizador que tem acesso à informação disponibilizada na página Web;! Avançado: utilizador que herda os requisitos de acesso base e possui privilégios para requisitar os ficheiros XML;! Administrador: utilizador que têm acesso a todo o tipo de informação, gestão dos utilizadores e controlo dos respectivos acessos. R F0 R F02 R F03 R F04 R F05 R F06 R F07 R F08 R F09 R F0 R F R F2 R F3 R F4 RN F0 (Segurança) RN F02 (Latência) Tabela Requisitos funcionais Serviços Internos Gerar um documento XML com o aproveitamento escolar dos candidatos a benefícios sociais. Gerar um documento XML com informação sobre as propinas dos beneficiários da acção social. Gerar um documento XML com informação sobre o regime de estudos dos beneficiários da acção social. Gerar um documento XML com a situação dos candidatos a bolsa. Consultar situação do candidato através do número do documento identificação. Consultar situação do candidato por número de aluno. Consultar dados do aluno sobre o aproveitamento, através do número do documento de identificação. Serviços Externos Gerar um documento XML com os alunos matriculados (Instituto Acção Social). Consultar dados do aluno através do número do documento identificação (Companhia Aérea). Gestão de Utilizadores Gerir utilizadores Aceder aos sistemas de gestão de bases de dados existentes. Interface Desenvolver uma interface gráfica para administração dos utilizadores do WS. Desenvolver aplicações Cliente para aceder aos serviços disponibilizados pelo WS. Dados Preparar as vistas dos sistemas de gestão de bases de dados. Tabela 2 Requisitos não funcionais Cada WS deve estar instalado num servidor autenticado com HTTPS. Existir uma infra-estrutura de rede que cumpra os requisitos mínimos de comunicação e falhas. Na Fig. 3, apresentamos um diagrama de casos de uso para descrever a interacção entre os utilizadores e o WS onde: Registar utilizador: um utilizador, com privilégios de administrador, devidamente autenticado e autorizado inicia o processo de criação de um novo utilizador. Para criar o registo, o administrador tem de introduzir o login, a password, o , o nome e o grupo; Gerir utilizador: a aplicação Cliente requisita ao WS a lista dos utilizadores registados. Esta é apresentada pela aplicação Cliente na forma de tabela. Após estes registos serem visualizados será requisitado ao WS o método que permite realizar alterações nos dados dos utilizadores; Autenticar: o utilizador tem de estar autenticado através do seu login e password; Dados_SASU A (Dados_SE G_SO C I A L, Dados_C O M PA E R E A): a aplicação Cliente requisita ao WS, através do método que apresenta os parâmetros de consulta. O WS responde à requisição, de acordo com o perfil do utilizador autenticado, enviando a informação solicitada; Propina (Aproveitamento, Candidatura e Regime de estudo): a aplicação cliente requisita ao WS, através do método que apresenta os parâmetros de consulta. O WS responde à requisição, de acordo com o perfil do utilizador autenticado, enviando a informação solicitada num documento XML. Administrador Utilizador base/avançado Registar utilizador Gerir utilizador Dados_SEG_SOCIAL Dados_COMPAEREA Dados_SASUA Candidatura Aproveitamento Propina Regime estudo Autenticar Figura 3 Interacção entre WS e utilizador. IV. DESENHO Nesta secção vamos apresentar algumas partes do desenho, usando o UML [], através de um diagrama de pacotes, para descrever a arquitectura do sistema e as interacções, um diagrama de actividades, para descrever o processo de requisição de um serviço ao WS, e diagramas de sequência, para algumas operações que utilizam serviços internos e externos. Gestão académica UAç Gestão de utilizadores Gestão de serviços Figura 4 Diagrama de pacotes. O diagrama de pacotes (hierárquico) na Fig. 4, reflecte a nova organização proporcionada pela integração de sistemas de informação, nomeadamente dos SA e dos SASUA, numa dependência mútua, e a sua relação com outras entidades externas, nomeadamente com a CA e o IAS. Devemos salientar que a "#$%&!' (#' )%*+*,-(!.#$ está separada para que a publicação de serviços seja independente dos utilizadores que acedem a estes serviços. 292 CISTI 200

4 Gestão de serviços Internos SA SASUA Externos Base Dados Cliente SGBD WS SGBD WS CA IAS Pedido de serviço Validar utilizador Verificar utilizador e credenciais Figura 5 Diagrama de pacotes "#$%&!'(#'$#./*0!$. Cada unidade pertencente aos Serviços Internos adopta o mesmo modelo de integração de dados para exportação de dados (ver Fig. 5), i.e., publica um catálogo de serviços, via ficheiros WSDL, os quais são implementados com recurso aos respectivos sistemas de gestão de bases de dados, através de vistas geradas para o efeito, de forma a garantir que os serviços não tenham acesso directo ao respectivo sistema de gestão de bases de dados. Como podemos observar na Fig. 6, a "#$%&!' (#' )%*+*,-(!.#$ permite criar grupos de utilizadores que requisitam serviços, classificados por externos (classe 2%#.3!4' e internos (classe 53%#.3!), publicados por entidades (classe 3%*(-(#). Este subsistema permite implementar a nossa política de segurança no acesso ao catálogo de serviços disponibilizado pela UAç, através de um UDDI. A Fig. 7, apresenta uma visão funcional do sistema, descrevendo o processo de requisição de um serviço ao WS. Assim, um cliente faz um pedido de um serviço mas, antes o sistema verifica se este é um utilizador válido; caso seja, o serviço é executado; caso contrário, é emitida uma mensagem de falha de autenticação e o serviço não é executado. Informa falha autenticação Apresenta resultado Executa o serviço [ false ] [ true ] Figura 7 Diagrama de actividade de acesso a um serviço. O diagrama da Fig. 8 faz parte do caso de uso propina (requisito R F02). Após a autenticação de um utilizador, que é realizada através da introdução de um login e password, é retornado, como resposta, um documento XML. Aplicação cliente propina() retorna ficheiro XML ligar() retorna dados Base dados Figura 8 Diagrama de sequência propina. Interage com ORACLE e MS SERVER Contacto +idcontacto : int +desccontacto : string +obscontacto : string +ciracontacto() +eliminacontacto() +alteracontacto() TipoContacto +idtipo : int +desctipo : string +criatipo() +eliminatipo() +alteratipo() 0..* 0..* Pessoa +bi : int +nome : string +contacto : int + string +obspessoa : string +criapessoa() +eliminapessoa() +alterapessoa() 0..* Entidade +identidade : int +descentidade : string +responsavel : string +obsentidade : string +criacontacto() +eliminacontacto() +alteracontacto() 0..* 0..* Interno Utlizador -idutilizador : int -bi : int -username : string -password : string -alias : string +criautilizador() +eliminautilizador() +alterautilizador() Grupo 0..* +idgrupo : int +descgrupo : string +obsgrupo : string +criagrupo() +eliminagrupo() +alteragrupo() Servico +idservico : int +descservico : string +obsservico : string +criaservico() +eliminaservico() +alteraservico() * * Externo O diagrama da Fig. 9 faz parte do caso de uso dados companhia aérea (requisito R F09). Após estabelecida a ligação do utilizador, é retornada uma mensagem com informação do tipo complexo (e.g. vector). Aplicação cliente dados_sata() retorna vector com os dados ligar() retorna dados Base dados Interage com ORACLE e MS SERVER Figura 9 Diagrama de sequência dados companhia aérea. V. IMPLEMENTAÇÃO COM WEB SERVICES Nesta secção vamos apresentar o essencial da nossa implementação, baseada em WS, para a integração dos sistemas de informação dos SA e dos SASUA, segundo a estrutura apresentada na Fig. 0. Mas, antes, vamos descrever, sucintamente, a estrutura e o funcionamento de um WS. Figura 6 Diagrama de classes "#$%ã!'(#')%*+*,-(!.#$. Um WS é constituído por componentes de software que oferecem uma funcionalidade específica, podendo ser acedidos CISTI

5 por diferentes sistemas, através dos padrões estabelecidos pelo W3C, como o HTTP, XML e SOAP. SOAP Cliente Internet WSDL Pesquisa UDDI WSDL Figura 0 Esquema conceptual de um WS. O principal objectivo de um WS é proporcionar a interoperabilidade [5] entre sistemas distribuídos, independentemente da plataforma e da linguagem de programação, permitindo uma melhor interligação e integração das aplicações. Esta interligação tem como princípio facilitar os processos de negócio, permitindo que aplicações, desenvolvidos em plataformas diferentes e, isoladas, possam funcionar de forma conjunta e integrada. Na Fig. 0, apresentamos um esquema conceptual de um WS, onde se pode observar uma aplicação cliente interagindo com um WS através do SOAP via Internet. O WS incorpora também um ficheiro Definition Language (WSDL) para descrever as interfaces dos serviços disponibilizados pelo WS, os tipos de dados e os protocolos para a comunicação das mensagens. Outro elemento presente na Fig. 0, é o Universal Description, Discovery and Integration (UDDI), que é utilizado para a publicação e descoberta dinâmica via Internet. A nossa estratégia para integrar os SA e os SASUA foi desenvolver um WS, na realidade descrever um ficheiro WSDL e implementar, usando uma ou mais linguagens de programação, os interfaces dos serviços publicados, para os SA (ver Fig. ) e outro para os SASUA (ver Fig. 2). No primeiro caso, usamos unicamente o PHP, utilizando a classe NuSOAP, e, para o segundo, somente o Java, utilizando a API JAX-WS. Estes WS estão registados num UDDI local suportado pelo Windows Server 2003 instalado nos SASUA. Figura 2 WS do SASUA. Como podemos observar na Fig. 2, estão disponíveis 3 serviços publicados pelos SASUA que cumprem, respectivamente, os requisitos RF04, RF05 e RF06. O ambiente de execução do WS nos SASUA é composto pelo Apache Tomcat que tem uma boa integração com o NetBeans (o IDE utilizado para desenvolver toda a programação dos serviços) e com a API JAX-WS.! Os serviços implementados nos WS estão registados num servidor UDDI (ver Fig. 3), criado para o efeito, permitindo que estes serviços possam ser consultados através da rede Internet. Para esta implementação foi utilizado o serviço UDDI disponível no Windows Server A principal vantagem deste serviço é ser implementação por um utilizador não especializado. Existem outras alternativas desenvolvidas na linguagem Java tais como o JUDDI, UDDI4J, Glue, [7] mas, infelizmente, estas disponibilizam documentação muito técnica que dificulta a utilização por programadores Java menos experientes. Figura 3 Servidor UDDI. Figura WS do SA. Como podemos observar na Fig., estão disponíveis 6 serviços publicados pelos SA que cumprem, respectivamente, os requisitos RF0, RF02, RF03, RF07, RF08 e RF09. Nesta implementação utilizamos o WampServer 2, que é uma aplicação de desenvolvimento Web para Windows, que permite criar aplicações Web com Apache, PHP e base dados MySQL. VI. PLANO DE TESTES Elaboramos um plano de testes para: identificar informações existentes e os componentes de software que devem ser testados; listar dos requisitos de teste recomendados; recomendar e descrever as estratégias de teste a serem utilizadas; identificar os recursos necessários e fornecer estimativas dos esforços de teste (ver Tabela 3). Tabela 3 Plano de testes Descrição do teste Teste às bases de dados As informações de registo dos utilizadores podem ser inseridas e recuperadas. Os grupos e serviços podem ser inseridos e recuperados. Os perfis dos utilizadores e as informações da conta podem ser inseridos e recuperados. Testado 294 CISTI 200

6 Teste funcional Os utilizadores conseguem ver as informações sobre os serviços disponibilizados pelo WS. Os serviços estão de acordo com os requisitos funcionais. Teste à interface do WS Navegar por todos os serviços referidos no caso de uso, verificando se as configurações dos serviços podem ser facilmente acedidas. Verificar se é gerado o documento WSDL pelo WS. Teste de desempenho O tempo de resposta da interface do WS. O tempo de resposta durante uma ligação com modem de 56Kbps. O tempo de resposta durante uma ligação utilizando rede local (LAN ou WLAN). A publicação dos serviços na Web, utilizando o UDDI. Teste de carga A resposta do sistema com 3 utilizadores em simultâneo. A resposta do sistema com 6 utilizadores em simultâneo. A resposta do sistema com 0 utilizadores em simultâneo. Teste de segurança e de controlo de acesso Verificar se os não utilizadores registados realmente não conseguem executar os serviços. Teste de configuração O WS utilizando o browser Microsoft Internet Explorer, versão 7.x e 8.x. O WS utilizando o browser Mozzila Firefox, versão 3.x. Teste de instalação O servidor está ligado a uma UPS. O servidor está instalado num espaço protegido a climatizado. [3] G. Alonso, F. Casati, H. Kuno and V. Machireju, s: Concepts, Architectures, and Applications, Springer, Interdependência e integração: tendência onteudo=958 perabilidade de Sistemas sinfic/newletter43/dossier.html developer/ technicalarticles/webservices/restful/, [7] Soapclient, ResourcesUDDI, UDDI/Resources.html VII. COMENTÁRIOS DE FECHO O sistema, agora, desenvolvido representa uma parcela da integração dos sistemas de informação da UAç. Mas contribuirá, certamente, para um ganho real de produtividade e eficiência das suas unidades orgânicas e a sua relação com várias entidades externas que participam na sua gestão académica e financeira. Pensamos que esta solução, até aquilo que conhecemos, pode contribuir para decidir opções técnicas e organizacionais, mais económicas, flexíveis, escaláveis e reutilizáveis, em instituições congéneres, no que diz respeito à integração de sistemas de informação. No futuro próximo, pretendemos avançar para a consolidação e evolução desta solução através: da expansão da integração de outros sistemas de informação da Instituição (e.g. gestão financeira); do desenvolvimento de mais ligações a outras entidades externas à Instituição (e.g. companhia de seguros); da reinstalação do UDDI, numa unidade independente das unidades orgânicas existentes na Instituição, recorrendo a um produto open-source (e.g. juddi); da integração de WS baseados em RESTful [6] e JSON tendo em vista a extensão da solução para dispositivos móveis (e.g. com Android). REFERÊNCIAS [] M. Fowler, UML Distilled: A Brief Guide to the Standard Object Modelling Language, Third Edition, Addison Wesley, [2] T. Erl, SOA: Principles of Service Design, Prentice Hall, CISTI