SINS: Um ambiente para geração de aplicações baseadas em serviços

Transcrição

1 SINS: Um ambiente para geração de aplicações baseadas em serviços Sérgio Larentis Jr (Unisinos) Andrêsa Larentis (Unisinos) Jorge Barbosa (Unisinos) Sérgio Crespo C. S. Pinto (Unisinos) SBSI 2008 Roteiro Introdução Motivação Objetivo do trabalho Revisão Bibliográfica Trabalhos Relacionados Modelo do SINS Implementação do SINS Estudo de Caso Considerações Finais Referências Bibliográficas 2

2 Introdução Paradigmas atuais, baseados em objetos, classes ou includes, não conseguem dar a correta idéia de componentização pela falta de interoperabilidade entre plataformas ou até mesmo paradigmas; Uma Idéia análoga as linhas de produção e desenvolvimento por partes independentes de software é o SOA (Service Oriented Architecture), que tem como pilares principais: Interoperabilidade, Independência de componentes e, reuso 3 Motivação Desenvolvimento da engenharia de software ataca duas vertentes: qualidade e produtividade Paralelo a isso SOA surge como complemento aos esforços atuais já despendidos nestas duas vertentes, ajudando tanto na qualidade quando na produtividade Apesar de vários Big Players já estarem focadas em SOA, ainda não há um ambiente capaz de gerar aplicações a partir dos serviços existentes sem a necessidade de codificação, principal motivação para a criação do SINS (acrônimo recursivo de Sins Is Not SOA), mostrado nesta apresentação. 4

3 Objetivo do trabalho Criar um ambiente para geração de aplicações baseadas em serviços que é capaz de utilizar serviços existentes em um contexto e disponibilizados em forma de Web Services, indexálos, catalogá-los para posterior uso e, por fim, prover uma interface ao usuário que lhe permita compor aplicações baseadas nestes serviços. 5 Revisão Bibliográfica Principais tecnologias aplicadas no trabalho: Web Services SOA Composite Applications 6

4 Revisão Bibliográfica Web Services Figura 1. Papéis, operações e artefatos de Web Services [Kreger, 2001] 7 Revisão Bibliográfica SOA é um novo paradigma de desenvolvimento de aplicações cujo objetivo é criar módulos funcionais chamados de serviços, com baixo acoplamento permitindo a reutilização de código [Sampaio, 2006] Figura 2. Camadas da arquitetura SOA [Erl, 2006] 8

5 Revisão Bibliográfica Composite Application Uma composite application é: uma coleção de serviços que foram montados para fornecer uma potencialidade ao negócio. Estes serviços são artefatos que podem ser desdobrados independentemente, permitindo a composição e utilização das capacidades de plataformas específicas [Banerjee, 2007]. Figura 3. Modelo de composite application [Banerjee, 2007]. 9 Trabalhos Relacionados Trabalhos acadêmicos relacionados: Camada de apresentação e SOA Ferramentas de desenvolvimento voltadas a SOA oferecidas e disponibilizadas comercialmente: Solução da IBM (IBM SOA Foundation) Solução da Microsoft (Microsoft Biztalk) Solução da SAP (Sap NetWeaver) Solução da Oracle (Oracle SOA Suite) 10

6 Trabalhos Relacionados Camada de apresentação e SOA O trabalho desenvolvido por Link tem como foco principal a camada de apresentação de SOA e a interface para o usuário final, não estando no escopo do trabalho a conexão com a camada de processos. O trabalho baseia-se na idéia de duplicar a interface de um sistema, convertendo-o para um portlet, de forma que ele possa ser usado no ambiente antigo e em ambiente SOA. Consiste em três etapas iterativas : 1. Identificar os componentes de apresentação reutilizáveis na aplicação legada; 2. Duplicar o componente de apresentação usando tecnologia de portlet; 3. Integrar este portlet novamente para o cliente legado. [Link et al, 2006] 11 Trabalhos Relacionados IBM SOA Foundation Oferece uma plataforma para implantação e gerenciamento de SOA; Baseada em padrões abertos como BPEL (Business Process Execution Language); Inclui um ambiente de desenvolvimento, gerenciamento de serviços, integração de aplicações e processo de serviços em tempo de execução; A ferramenta IBM WebSphere Integration Developer fornece adaptadores para diferentes bancos de dados ou sistemas de gestão com o objetivo de permitir conexão dos serviços com diferentes fontes de dados; [IBM, 2005] 12

7 Trabalhos Relacionados Microsoft Biztalk No ambiente Microsoft é considerada plataforma de desenvolvimento SOA; Ainda que compatível com BPEL e demais padrões abertos, usa adaptadores e faz tratamento de dados de forma proprietária; Cria soluções para integração de processos de negócios e incorpora recursos de integração e acesso a fontes de dados diversas para disponibilização de seus dados como Web Services; [Microsoft, 2005a] 13 Trabalhos Relacionados Sap NetWeaver Criou uma solução denominada ESA (Enterprise Services Architecture), com intuito de que os sistemas legados se convertam a essa arquitetura; Todas novas versões do SAP, assim como suas extensões, serão feitos sob ESA que define as camadas e forma de desenvolvimento (trata-se de um SOA com ESB); NetWeaver é a plataforma voltada para integração, colaboração e interação com usuário; busca dados de aplicações ou componentes e disponibiliza serviços para as composite applications; O XI é um componente de software no centro da arquitetura ESA com o intuito de fornecer funções de acesso a dados e aplicações através de adaptadores, gerenciamento de serviços e monitoramento; [Heuser, 2004] 14

8 Trabalhos Relacionados Oracle SOA Suite Oferece uma plataforma que permite desde a especificação até implantação de SOA; Trabalha com padrões abertos e são integráveis com ferramentas de outros fornecedores, por exemplo, BPEL; O Oracle JDeveloper funciona como um ambiente para desenvolvimento de processos, programação de Web Services para serem inclusos como serviços e composição de aplicações; Permite gerenciar os serviços criados através do Oracle Web Services Manager, facilitando busca e evitando redundância de serviços. [Oracle, 2006] 15 Trabalhos Relacionados Oracle SOA Suite Por ser a ferramenta mais otimizada no que diz respeito a criação de composite applications, os passos para criação de uma aplicação no Oracle Jdeveloper serão listados para efeitos de comparação : Criação de um projeto Mapeamento dos Web Services a serem usados por UDDI Desenvolvimento das interfaces do sistema Mapeamento dos campos da aplicação com os campos e métodos dos Web Services correspondentes [Oracle, 2006] 16

9 Modelo do SINS Objetivos almejados: a organização de serviços de forma a facilitar seu uso diferenciando-se das soluções mostradas pelo fato de ter, além de UDDI, os serviços cadastrados em um banco de dados, permitindo a gestão sobre eles através de uma interface Web; a capacidade de geração de aplicações (composite applications) por um usuário, de acordo com suas necessidades, apenas combinando serviços existentes sem a necessidade de codificação ou envolvimento de profissionais da área de software - diferenciando-se das soluções mostradas por não necessitar codificação tanto para o consumo de serviços quanto para a geração das composite applications. 17 Modelo do SINS Figura 4. Arquitetura do SINS 18

10 Modelo do SINS Componentes da arquitetura: Serviços : São os Web Services que serão utilizados pelo ambiente. Biblioteca de serviços: constitui o conjunto de serviços (Web Services) conhecidos pelo ambiente (entenda-se cadastrados em seu banco de dados) ou passíveis de descoberta através de um diretório UDDI acessível pelo ambiente; Engine de Indexação: constitui de um motor de indexação que percorre o banco de dados, onde estão armazenadas as informações sobre os serviços, e relaciona os serviços existentes, de forma que possa auxiliar o usuário na posterior confecção de uma composite application; WS Consumer: é a parte da composite application responsável por acessar os Web Services. 19 Modelo do SINS Componentes da arquitetura (continuação): Servlet: é responsável por processar as requisições oriundas de um browser e gerar as interfaces das composite applications; Documento XML: é o documento que armazena os dados que servem como parâmetros para geração das composite applications; Gerador XML com definição de interface: esse módulo gera um XML a partir das configurações feitas pelo usuário que contém os dados necessários para geração das composite applications; 20

11 Modelo do SINS Componentes da arquitetura (continuação): Interface de configuração: trata-se de uma interface disponibilizada pelo ambiente que fornece as operações necessárias para criação, configuração e alteração de composite applications. Esta interface deve ser utilizada pelo usuário de configuração (sendo esse um profissional com conhecimento de operação de computadores e, principalmente, das regras de negócio envolvidas na aplicação); Composite Application: é a aplicação em si. Trata-se de uma interface que disponibilizará o uso de serviços mapeados na sua configuração (através da interface de configuração). Os serviços são gerenciados pela camada de orquestração do ambiente SINS. 21 Modelo do SINS Fluxo do funcionamento de uma Composite Application : Figura 5. Fluxo de uma Composite Application 22

12 Modelo do SINS Composite application São geradas pelo ambiente e possuem o mesmo padrão visual, sendo possível apenas pequenas customizações no momento da criação da aplicação; A aplicação não existe, de fato, é criada em tempo real através da leitura de um arquivo XML que contém suas definições; São geradas pelo mesmo servlet, o que é ótimo no ponto de vista de re-uso; As regras de negócios, validação e dados são inerentes aos serviços, sendo as composite application apenas uma interface para o usuário. 23 Implementação do SINS O ambiente SINS foi implementado utilizando a linguagem de programação Java 2 Enterprise Edition 5 (J2EE), servidor de aplicações Tomcat 6.0 e banco de dados Oracle 10g Express Edition. O protótipo da interface de configuração foi implementado em Java Server Pages (JSP). Além da própria linguagem Java, foi utilizado o Axis para parte de consumo de Web Services, o juddi para parte de consulta a catálogo de serviços, e o NetBeans 5.5 como IDE de desenvolvimento. 24

13 Implementação do SINS Figura 6. Componentes do Ambiente SINS 25 Implementação do SINS Figura 7. Processo de geração de aplicações 26

14 Implementação do SINS Figura 8. Tela de cadastro de serviços 27 Implementação do SINS Figura 9. Tela de geração de aplicações 28

15 Estudo de Caso O estudo de caso apresentado trata de um projeto real de implementação de arquitetura SOA realizado por uma empresa de software do estado do Rio Grande do Sul para uma empresa multinacional da área farmacêutica. A empresa em questão não faz venda direta ao consumidor em alguns países (incluindo o Brasil) e por isso faz uso de distribuidores. Devido aos altos custos recorrentes em manter sistemas de distribuição isolados e com alcance limitado (geralmente de apenas um país), essa empresa optou por criar um novo sistema em arquitetura SOA, de modo a reutilizar ao máximo os seus sistemas legados, padronizar todos os sistemas em uma mesma arquitetura e interface e poder ter as customizações inerentes as diferentes regiões passíveis de serem feitas de forma rápida e com o menor custo possível. 29 Estudo de Caso O sistema em questão é chamado de Sistema de Distribuição e possui quatro funções: Registrar pedidos de produtos dos distribuidores; Executar um processo externo ao sistema para emissão de faturas aos distribuidores; Compatibilizar as unidades do estoque da empresa com as dos distribuidores, por exemplo: em alguns países usam-se litros e gramas, em outros, galões e onças. No Brasil vendem-se alguns produtos em embalagens de 20 comprimidos, em outros de 18; Compatibilizar os nomes de produtos entre a empresa e os distribuidores (produtos não necessariamente têm o mesmo nome em todos os países). 30

16 Estudo de Caso Figura 10. WBS do sistema original 31 Estudo de Caso Figura 11. WBS usando SINS 32

17 Estudo de Caso Tempo total Tempo Interface Custo Total Custo Interface (horas) (horas) Modo Usual R$ ,00 R$ 4.800,00 Com SINS 222 4,5 R$ ,00 R$ 175,28 Tabela 1. Comparativo projeto original x projeto com SINS Figura 12. Gráfico comparativo de tempo Figura 13. Gráfico comparativo de custo 33 Considerações finais Alguns critérios foram definidos para comparação entre as ferramentas apresentadas anteriormente e o SINS : Necessidade de codificação para consumir serviços: esse critério avalia a capacidade da ferramenta de consumir serviços (sob a forma de Web Services) sem a necessidade de codificação; Catálogo de serviços: é o repositório que centraliza dados dos serviços disponíveis em um ambiente facilitando seu uso; Geração de composite applications: avalia a capacidade das ferramentas gerarem aplicativos (composite applications) a partir de serviços, sem necessidade de recodificar toda a interface. 34

18 Considerações finais Tabela comparativa 35 Tabela 2. Comparativo trabalhos relacionados x SINS Considerações finais Limitações o SINS não possui nenhum mecanismo para otimização de carga ou pooling. Tendo em vista que o handler de todas as requisições para geração de composite applications é um único servlet, pode ser necessário configurar otimizações a nível de servidores ou application server quando as aplicações puderem ser submetidas a um grande número de acessos. (NLB, pooling, clustering, etc); o SINS não possui nenhum dispositivo de autenticação nas composite applications, assim como também não é capaz de autenticar-se contra Web Services que façam uso de algum aparato de segurança ou usem WS-Security; por basear-se no conceito de SOA, o SINS somente é compatível com Web Services que tenham sido desenvolvidos sob os conceitos de serviço. 36

19 Considerações finais Trabalhos futuros capacidade de gerar interfaces baseadas em um modelo gráfico, o que permitiria organizar melhor as informações na tela além de gerar interfaces de melhor qualidade; mecanismos de autenticação e uso de WS-Security; mecanismos de otimização de desempenho, como o uso de threading no servlet gerador de composite applications; capacidade de exportar as composite applications respeitando os padrões de portlets, o que permitira se uso diretamente dentro de grande parte das ferramentas de portal que existem hoje; melhoria da parte de busca, catalogação e otimização de serviços. Seja aumentando e melhorando a taxonomia do banco de dados, seja integrando o ambiente a serviços UDDI distribuídos, permitindo a consulta a mais de um repositório simultaneamente. 37 Referências Bibliográficas [Erl, 2006] Erl, T. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, [Heuser, 2004] Heuser, L.. Enterprise Services Architecture & Semantic Web Services. SAP Research. SAP Group [IBM, 2005] IBM Corporation. IBM SOA Foundation: providing what you need to get started with SOA. Service oriented architecture solutions. White Paper, [Kreger, 2001] Kreger, H. Web Services Conceptual Architecture. IBM Software Group, May [Manolescu and Lublinsky, 2007b] Manolescu, D.; Lublinsky, B.. Draft Pattern: Movement: Service-Oriented Decomposition, do livro Enterprise Patterns - Services, Orchestration and Beyond, para ser publicado por Morgan-Kaufmann. [Microsoft, 2005a] Microsoft Corporation. Business Activity Monitoring - BAM. Microsoft White Paper. April,

20 Referências Bibliográficas [Oracle, 2006] Oracle SOA Suite. Quick Start Guide 10g ( ). September, [Parnas, 1972] Parnas, D. L. On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12). December, [Sampaio, 2006] Sampaio, C. SOA e Web Services em Java. Rio de Janeiro: Editora Brasport [Link et al, 2006] Link, S., Jakobs, F., Neer, L., Abeck, S. Architecture of and Migration to SOA s Presentation Layer, C&M Research Report, Universität Karlsruhe, Sins: Um ambiente para geração de aplicações baseadas em serviços Obrigado pela atenção!