UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UTILIZAÇÃO DA ARQUITETURA ORIENTADA A SERVIÇO (SOA) COMO FERRAMENTA PARA OTIMIZAÇÃO DE PROCESSOS DE NEGÓCIOS Área de Sistemas de Informação por Ivan Correia Filagrana Alexandre Biazin, M.Sc. Orientador Itajaí (SC), julho de 2008

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UTILIZAÇÃO DA ARQUITETURA ORIENTADA A SERVIÇO (SOA) COMO FERRAMENTA PARA OTIMIZAÇÃO DE PROCESSOS DE NEGÓCIOS Área de Sistemas de Informação por Ivan Correia Filagrana Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Alexandre Biazin, M.Sc. Itajaí (SC), julho de 2008

3 DEDICATÓRIA Dedico este trabalho a Deus fonte de todo conhecimento e sabedoria. Aos meus grandes heróis, meus pais (Jolmir e Teresa) pelo apoio, educação, carinho e amor que sempre me deram. A minha amada esposa Patricia e ao meu maravilhoso e amado filho Lucas Yan, pelos sacrifícios, paciência, compreensão e motivação. ii

4 AGRADECIMENTOS Agradeço a Deus fonte de todo conhecimento e sabedoria pela minha vida, pelas conquistas, pelos amigos e familiares que tenho; Ao meu grande herói e pai Jolmir, que sempre me apoiou, incentivou e me orientou rumo ao conhecimento e honestidade; A fantástica heroína da minha vida, minha mãe Teresa, que com suas palavras de apoio, sempre me estimulou a vencer todos os desafios e me mostrou que tudo se constrói com esforço e dedicação; Aos meus sogros Maurílio e Helena que sempre me apoiaram e incentivaram para que eu alcançasse o sucesso neste trabalho; A minha grande família que sempre torceu por mim e me incentivou; Ao meu amado filho Lucas Yan motivo maior de minhas conquistas, pela compreensão e motivação durante esta etapa da minha vida; A minha amada e querida esposa Patricia pelos sacrifícios, paciência, compreensão, motivação e companheirismo dedicados em cumplicidade para que eu pudesse concluir com êxito este trabalho; Ao meu orientador Alexandre Biazin, pelo apoio, orientação, tempo e conhecimento disponibilizados; Aos professores Luis Carlos Martins (Luca) e Ovídio Felippe Pereira da Silva Junior (O Mestre) que além de avaliadores do meu trabalho foram também incentivadores, orientadores e que ainda disponibilizaram valiosas horas de conversa e orientação; Aos meus colegas de trabalho Sérgio, Michel, Jorge e Paulo que sempre ouviram minhas idéias e incentivaram e apoiaram o desenvolvimento deste trabalho. Ao amigo e colega de graduação Leandro que sempre contribui com palavras de apoio e incentivo para o sucesso deste trabalho; Ao Maicon meu grande amigo de graduação e exemplar profissional, na qual tenho a honra de ser colega de trabalho, que me apoiou, auxiliou e contribuiu maciçamente com seus conhecimentos para o desenvolvimento deste trabalho. iii

5 SUMÁRIO LISTA DE ABREVIATURAS...vii LISTA DE FIGURAS...viii LISTA DE TABELAS...x RESUMO...xi ABSTRACT...xii 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA ARQUITETURA ORIENTADA A SERVIÇO (SOA) Conceituando Serviço Características chaves dos Serviços Conceituando SOA Elementos fundamentais da Arquitetura Orientada a Serviço Aplicações frontend Serviços Repositório de serviço Barramento de serviço Considerações sobre os Elementos da SOA Características da Arquitetura Orientada a Serviço Tecnologias Web Services Extensible Markup Language (XML) Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Universal Description, Discovery and Integration (UDDI) Segurança BUSINESS PROCESS MANAGEMENT (BPM) - GESTÃO DE PROCESSOS DE NEGÓCIOS Processos de Negócios Gestão de Processos (BPM) iv

6 2.2.3 Business Process Management Systems (BPMS) Sistemas de Gestão de Processos de Negócios Benefícios do uso combinado de BPM, SOA e Web Services Orquestração e Coreografia Business Process Execution Language (BPEL) Linguagem de Execução de Processos de Negócio PROJETOS SIMILARES CONSIDERAÇÕES DA FUNDAMENTAÇÃO TEÓRICA DESENVOLVIMENTO CENÁRIO ATUAL CENÁRIO PROPOSTO Modelagem do Processo de Negócio Pedidos Modelagem - Web Service WS_PEDIDOS Integração Web Services e Ferramenta Pedidos On-Line Modelagem - Web Service WS_VALIDACAO Modelagem - Web Service WS_ANALISE_FIN Modelagem - Web Service WS_ANALISE_LOG Modelagem - Web Service WS_ANALISE_CML Modelagem do Processo de Negócio Acompanhamento de Pedidos Repositório de Serviços Requisitos Regras de Negócio (RN) Requisitos Funcionais (RF) Requisitos Não Funcionais (RNF) IMPLEMENTAÇÃO Metodologia e Tecnologias da Implementação Metodologia - Desenvolvimento em Camadas Tecnologias utilizadas na Implementação Estrutura do Projeto Padrão de Implementação Implementação Web Service WS_PEDIDOS Workflow WFPedidos Estrutura string XML de Entrada e Saída Implementação Web Service - WS_VALIDACAO Implementação Web Service WS_ANALISE_FIN Implementação Web Service WS_ANALISE_LOG Implementação Web Service WS_ANALISE_CML Implementação Web Service WS_ACMP_PEDIDOS Implementação Repositório de Serviços Testes e Validações dos Processos de Negócios, Serviços e Repositório de Serviços Implantação e Validação do Protótipo da SOA v

7 4 CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS A TELAS DA FERRAMENTA DE PEDIDOS ON-LINE A.1 TELAS PROCESSO DE NEGÓCIO PEDIDOS A.2 TELAS PROCESSO DE NEGÓCIO - ACOMPANHAMENTO DE PEDIDOS B INFORMAÇÕES GERAIS DOS WEB SERVICES B.1 WEB SERVICE WS_VALIDACAO B.2 WEB SERVICE WS_ANALISE_FIN B.3 WEB SERVICE WS_ANALISE_LOG B.4 WEB SERVICE WS_ANALISE_CML B.5 WEB SERVICE WS_ENVIA_ B.6 WEB SERVICE WS_CLIENTES B.7 WEB SERVICE WS_CONDPG B.8 WEB SERVICE WS_VENDEDORES B.9 WEB SERVICE WS_TABPRECO B.10 WEB SERVICE WS_PRODUTOS B.11 WEB SERVICE WS_COTAS vi

8 LISTA DE ABREVIATURAS ASP BI BPEL BPEL4WS BPM BPMS CGI ERP ETL HTML HTTP IBM IIS JSP KPI LINQ SGML SLA SOA SOAP TCC TI UDDI UNIVALI W3C WCF WS-BPEL WSC WSDL WSFL WSO WWF XML XSD Active Server Pages Business Intelligence Business Process Execution Language Business Process Execution Language for Web Services Business Process Management Business Process Management Systems Common Gateway Interface Enterprise Resource Planning Extract Transform Load HyperText Markup Language Hypertext Transfer Protocol International Business Machines Internet Information Services Java Server Pages Key Performance Indicator Language Integrated Query Standard Generalized Markup Language Service Leve Agreement Service-oriented Architecture Simple Object Access Protocol Trabalho de Conclusão de Curso Tecnologia da Informação Universal Description, Discovery and Integration Universidade do Vale do Itajaí World Wide Web Consortium Windows Communication Foundation Web Services Business Process Execution Language Web Services Coreography Web Services Description Language Web Services Flow Language Web Services Orchestration Windows Workflow Foundation Extensible Markup Language XML Schema Definition Language vii

9 LISTA DE FIGURAS Figura 1. Serviços podem encapsular lógica sob várias formas...9 Figura 2. Aplicações frontend consumindo serviços e serviços consumindo serviços...10 Figura 3. Uma mensagem existe como uma unidade independente de comunicação...11 Figura 4. Visão simplificada da SOA...14 Figura 5. O Triângulo da SOA...15 Figura 6. Serviços e aplicações frontend são os principais componentes da SOA Figura 7. O ciclo de vida estimado de dados, serviços, aplicações frontend e tecnologias são diferentes...17 Figura 8. A operação AtualizaTudo, encapsula uma composição de serviços Figura 9. Um serviço reutilizável apresenta operações reutilizáveis...23 Figura 10. Serviços autônomos têm controle sobre recursos fundamentais Figura 11. Arquitetura básica de web services...27 Figura 12. Diferenças entre (a) aplicação monolítica com integração de funcionalidades, e (b) aplicação distribuída usando funcionalidades baseadas em web services Figura 13. Evolução de Aplicações Web para Web Services Figura 14. Múltiplas tecnologias de web services...31 Figura 15. Um documento XSD schema...32 Figura 16. Estrutura Sintática da WSDL...33 Figura 17. A rede lógica de web services...34 Figura 18. Estrutura de uma mensagem SOAP...35 Figura 19. A rede lógica de web services...36 Figura 20. Arquitetura do WS-Security...38 Figura 21. Processo de negócio simples...40 Figura 22. Componentes básicos de um BPMS Figura 23. Aplicações típicas Figura 24. SOA, BPM e Web Services Figura 25. Orquestração de Serviços...47 Figura 26. Coreografia de Serviços...48 Figura 27. Comparação entre orquestração e coreografia de Web services...49 Figura 28. Definição de um processo WS-BPEL...50 Figura 29. Orquestração de Web services com WS-BPEL...52 Figura 30. Fluxo do Processo de Negócio - Pedidos...57 Figura 31. Fluxo do Processo de Negócio - Digitação do Pedido...58 Figura 32. Fluxo do Processo de Negócio Análise Financeira Figura 33. Fluxo do Processo de Negócio Análise Logística Figura 34. Fluxo do Processo de Negócio Análise Comercial...61 Figura 35. Fluxo do Processo de Negócio Acompanhamento de Pedidos...62 Figura 36. Visão geral Processo de Negócio Pedidos...64 Figura 37. Consumindo o WS_PEDIDOS através de troca de mensagens...65 Figura 38. Comunicação Aplicação/Sistema X Web Service e Web Service x Web Service Figura 39. Visão geral - Web Service WS_ PEDIDOS Figura 40. Workflow - Web Service WS_PEDIDOS...70 Figura 41. Workflow - Web Service WS_VALIDACAO...73 Figura 42. Workflow - Web Service WS_ANALISE_FIN...74 Figura 43. Workflow - Web Service WS_ANALISE_LOG...76 Figura 44. Workflow - Web Service WS_ANALISE_CML...77 viii

10 Figura 45. Workflow - Web Service WS_ACMP_PEDIDOS...79 Figura 46. Repositório de Serviços para os Processos de Negócio...81 Figura 47. Pacotes da Solução Janela Solution Explorer Visual Studio...89 Figura 48. Camadas do Projeto e seus Pacotes...90 Figura 49. Comunicação entre Aplicação/Sistema com os Web Services...91 Figura 50. Interface IWS_PEDIDOS...92 Figura 51. Comunicação das Classes do Web Service WS_PEDIDOS...93 Figura 52. Workflow WFPedidos...97 Figura 53. Workflow WFPedidos - ValidacaoPedido...98 Figura 54. Workflow WFPedidos ExecutaAnalises...99 Figura 55. Workflow WFPedidos GravaPedido Figura 56. XML WS_PEDIDOS Figura 57. Interface IWS_VALIDACAO Figura 58. Workflow WFValidacao Figura 59. Interface IWS_ANALISE_FIN Figura 60. Interface IWS_ANALISE_LOG Figura 61. Interface IWS_ANALISE_CML Figura 62. Interface IWS_ACMP_PEDIDOS Figura 63. XML WS_ACMP_PEDIDOS Figura 64. Configuração - Servidor UDDI Figura 65. Configuração - Site UDDI Figura 66. Configuração Provedor de Serviços Figura 67. Serviços Publicados Figura 68. Estrutura UDDI Figura 69. Testes / Validação Web Services Figura 70. Testes / Validação Repositório de Serviços Figura 71. Interface de Inclusão do Pedido de Venda Figura 72. Interface de Inclusão do Pedido de Venda Consulta (Clientes, Condições de Pagamento, Produtos) Figura 73. Interface de Aprovação Financeira Figura 74. Interface de Aprovação Logística Figura 75. Interface de Aprovação Comercial Figura 76. Interface de Parâmetros: Processo de Negócio - Acompanhamento de Pedidos Figura 77. Interface de Acompanhamento de Pedidos Figura 78. XML WS_VALIDACAO Figura 79. XML WS_ANALISE_FIN Figura 80. XML WS_ANALISE_LOG Figura 81. XML WS_ANALISE_CML Figura 82. XML - WS_ENVIA_ Figura 83. XML WS_CLIENTES Figura 84. XML WS_CONDPG Figura 85. XML WS_VENDEDORES Figura 86. XML WS_TABPRECO Figura 87. XML WS_PRODUTOS Figura 88. XML WS_COTAS ix

11 LISTA DE TABELAS Tabela 1. Características dos componentes básicos do BPMS Tabela 2. Descrição do Processo de Negócio Digitação de Pedido Tabela 3. Descrição do Processo de Negócio Análise Financeira Tabela 4. Descrição do Processo de Negócio Análise Logística Tabela 5. Descrição do Processo de Negócio Análise Comercial...61 Tabela 6. Descrição do Processo de Negócio Acompanhamento de Pedidos...62 Tabela 7. Consumindo o WS_PEDIDOS através de troca de mensagens XML Tabela 8. Descrição das Camadas Tabela 9. Pacotes da Solução Tabela 10. Métodos do Web Service WS_PEDIDOS...93 Tabela 11. Estrutura XML de entrada WS_PEDIDOS Tabela 12. Estrutura XML de saída WS_PEDIDOS Tabela 13. Métodos do Web Service WS_VALIDACAO Tabela 14. Métodos do Web Service WS_ANALISE_FIN Tabela 15. Métodos do Web Service WS_ANALISE_LOG Tabela 16. Métodos do Web Service WS_ANALISE_CML Tabela 17. Métodos do Web Service WS_ACMP_PEDIDOS Tabela 18. Estrutura XML de entrada WS_ACMP_PEDIDOS Tabela 19. Estrutura XML de saída WS_ACMP_PEDIDOS (método ConsultaPedidos) Tabela 20. Estrutura XML de entrada WS_VALIDACAO Tabela 21. Estrutura XML de saída WS_VALIDACAO Tabela 22. Estrutura XML de entrada WS_ANALISE_FIN Tabela 23. Estrutura XML de saída WS_ANALISE_FIN Tabela 24. Estrutura XML de entrada WS_ANALISE_LOG Tabela 25. Estrutura XML de saída WS_ANALISE_LOG Tabela 26. Estrutura XML de entrada WS_ANALISE_CML Tabela 27. Estrutura XML de saída WS_ANALISE_CML Tabela 28. Métodos do Web Service WS_ENVIA_ Tabela 29. Estrutura XML de entrada WS_CLIENTES Tabela 30. Estrutura XML de saída WS_CLIENTES (método GetClientes) Tabela 31. Estrutura XML de saída WS_CLIENTES (método ValidaCliente) Tabela 32. Estrutura XML de entrada WS_CONDPG Tabela 33. Estrutura XML de saída WS_CONDPG (método GetCondPag) Tabela 34. Estrutura XML de saída WS_CONDPG (método ValidaCondPag) Tabela 35. Estrutura XML de entrada WS_VENDEDORES Tabela 36. Estrutura XML de saída WS_VENDEDORES (método GetVendedores) Tabela 37. Estrutura XML de saída WS_VENDEDORES (método ValidaVendedor) Tabela 38. Estrutura XML de entrada WS_TABPRECO Tabela 39. Estrutura XML de saída WS_TABPRECO (método GetTabPreco) Tabela 40. Estrutura XML de saída WS_TABPRECO (método ValidaTabPreco) Tabela 41. Estrutura XML de entrada WS_PRODUTOS Tabela 42. Estrutura XML de saída WS_PRODUTOS (método GetProdutosPed) Tabela 43. Estrutura XML de saída WS_PRODUTOS (método ValidaProduto) Tabela 44. Estrutura XML de entrada WS_COTAS Tabela 45. Estrutura XML de saída WS_COTAS (método GetCota) x

12 RESUMO FILAGRANA, Ivan Correia. Utilização da Arquitetura Orientada a Serviço (SOA) como ferramenta para otimização de processos de negócios. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, Em uma economia global altamente competitiva, as organizações precisam constantemente evoluir e amadurecer seus processos de negócios, em função de maximizar os resultados, reduzir custos e gerar negócios rapidamente. Desta forma, as organizações têm a necessidade de melhorar a relação entre as áreas de TI (Tecnologia da Informação) e de negócios, sendo que os processos de negócios dependem da TI para agilizar e viabilizar suas estratégias. Para auxiliar as organizações a superar estes desafios e a obter vantagem competitiva, a Arquitetura Orientada a Serviço (SOA) possibilita criar um ambiente de TI flexível, otimizar seus recursos e desenvolver processos de negócios mais eficientes. A Arquitetura Orientada a Serviço é uma aproximação da TI aos negócios das organizações, oferecendo uma infra-estrutura que possa responder rapidamente as pressões dos negócios e a desenvolver aplicações dinâmicas ao mesmo tempo. Através da composição de Web Services e da Gestão de Processos de Negócio (BPM), a SOA permite que as organizações alterem e desenvolvam rapidamente sistemas e aplicações que apóiam os processos de negócios agilizando e viabilizando suas estratégias, bem como a integração com sistemas e aplicações de parceiros de negócio ou da própria organização. Assim, este projeto apresenta a SOA, seus conceitos, características e tecnologias, e também a implementação da Arquitetura Orientada a Serviço em uma aplicação de Pedidos On-Line que possui processos de negócio que freqüentemente necessitam de alteração e evolução, em função de novas regras de negócio, novas funcionalidades e novas oportunidades de negócio. Palavras-chave: Arquitetura Orientada a Serviço. SOA. Sistemas distribuídos. Sistemas de Informação. xi

13 ABSTRACT In a highly competitive global economy, the organizations need to develop constantly and to mature their businesses processes, in function of maximizing results, reducing costs, and generating businesses quickly. In this way the organizations have the necessity to improve the relationship between the Information Technology (IT) areas and businesses, therefore businesses processes depend on IT to get their strategies move and to make them possible. To assist the organizations to overcome these challenges and obtain competitive advantage, the Service-oriented Architecture (SOA) makes possible to create a flexible IT environment, to optimize their resources and to develop more efficient businesses processes. The Service-oriented Architecture is an approximation between IT and the organizations businesses, offering an infrastructure that answers the pressures of the businesses quickly, and develops dynamic applications at the same time. Through the composition of Web Services, and the Business Process Management (BPM), SOA allows the organizations alter, and develop systems and applications that support businesses processes getting move and making possible their strategies quickly, as well as integration with systems and business partners applications or from own organization. Thus, this project presents SOA, their concepts, features and technologies, and also the implementation of the Service-oriented Architecture in an On-line Order Application, which has business processes that frequently need alteration and evolution, in function of new business rules, new functionalities and new business opportunities. Keywords: Service-oriented Architecture. SOA. Distributed Systems. Information Systems. xii

14 1 INTRODUÇÃO De acordo com Toffler (1980), o analfabeto do século XXI não será aquele que não conseguir ler ou escrever, mas aquele que não puder aprender, desaprender e, por fim aprender de novo. É exatamente o que acontece no mundo tecnológico de hoje. Não podemos mais nos dar ao luxo de aprender um assunto (tecnologia, metodologia, ferramenta, etc.) e nos fixarmos nele (SAMPAIO, 2006, p.1). Sampaio (2006, p.1) cita ainda: Assim é com as pessoas e com as empresas também. Todos têm que se adaptar em um mundo no qual a mudança é a única constante (que paradoxo bonito, não?). Para as empresas, a competitividade nunca foi tão acirrada. Táticas de guerra marketing agressivo, integração e parcerias são palavras-chave no mundo dos negócios de hoje. As empresas também não podem se dar ao luxo de se fixarem em uma tecnologia. Elas têm que se adaptar para oferecer serviços diferenciados para clientes e parceiros. Dentro deste contexto, verifica-se que as organizações precisam estar preparadas para oferecer a seus parceiros, clientes e fornecedores novos serviços, trocar novas informações de forma mais fácil e ágil, aprender e desaprender novas coisas. Neste inicio de século XXI, diversas organizações necessitam ou estão desenvolvendo/implementando sistemas que permitam a integração entre seus departamentos (parceiros internos) e integração entre parceiros externos (clientes, fornecedores). O ponto chave é encontrar uma solução que seja ágil, adaptável (aceite ambientes heterogêneos), flexível e que visualize os sistemas já existentes nas organizações, tais como sistemas legados, sistemas de gestão, etc. Dentro das organizações existe uma heterogeneidade grande de tecnologias, seja no quesito sistemas ou no quesito infra-estrutura. Considerando esta situação, tem-se o seguinte problema: dentro de uma organização existem diversos tipos de sistemas legados rodando em plataformas das mais diversas e também um sistema de gestão (ERP 1 ) que trocam informações entre si, ou seja, estão integrados. Na medida em que um dos sistemas sofre uma alteração, qualquer que seja, esta 1 Enterprise Resource Planning.

15 irá influenciar em todas as integrações existentes e quanto maior for o nível destas integrações, maiores são os custos financeiros, operacionais e de negócios para que todo o processo seja alterado devidamente. E quando todo o processo estiver finalizado, já é hora de uma nova manutenção. Segundo Sampaio (2006, p.2): [...] é necessário uma base fixa de aplicativos convencionais, responsáveis pelo processamento de transações da empresa. E esta base, geralmente, é pouco mutável. Mas é preciso também integrar, juntar pedaços de vários aplicativos (de plataformas diferentes) para oferecer um novo produto ou serviço. E isto tem que ser feito de maneira rápida e prática, sem esperar meses (ou anos) até quem um novo sistema seja criado. Sob esta ótica pode-se concluir que as organizações deveriam aprender a usufruir ao máximo os recursos disponíveis, recursos como sistemas: bancos de dados, softwares de desenvolvimento e infra-estrutura. É neste contexto que a SOA (Service Oriented Architecture - Arquitetura Orientada a Serviços) propõe uma nova metodologia no desenvolvimento de aplicações. A SOA surge como uma solução para vencer as dificuldades relativas ao desenvolvimento e integração de sistemas em ambientes heterogêneos e que possivelmente possam sofrer constantes mudanças. Mas o que é SOA? Segundo Carter (2007), SOA é a aproximação das áreas de TI e de negócios, integrando negócios, reutilizando serviços e processos de negócios, através de recursos tecnológicos. A SOA auxilia os negócios, inovando e assegurando que sistemas possam adaptar-se rapidamente, facilmente e economicamente, apoiando as necessidades dos negócios que mudam freqüentemente. Permite ainda flexibilizar os processos de negócios, fortalecendo a infra-estrutura de TI, reutilizando os investimentos e recursos já disponíveis. Assim, pode-se resumir que SOA é uma plataforma oferecida pela TI com diversos recursos tecnológicos e que auxilia as organizações para uma rápida e eficiente implementação de estratégias empresariais. A capacidade de melhorar e otimizar estratégias antecipando-se à concorrência é fundamental para o sucesso da organização. Assim, as organizações podem implementar novos recursos aos processos de negócios de forma rápida e mantendo o suporte aos processos já existentes. 2

16 Percebe-se porém, que o principal componente da SOA, são os serviços. Segundo Krafzig, Banke e Slama (2004), um serviço é um componente de software de significado funcional distinto que tipicamente encapsula um conceito de negócios de alto nível. Pode-se dizer ainda que, um serviço é um recurso computacional (rotina específica ou função) que é disponibilizado para que outros recursos computacionais (aplicações e sistemas) possam utilizá-lo como um serviço. Um serviço deve ser do tipo stateless, ou seja, sem dependências de outros serviços e deve possuir ainda uma interface bem definida de tal forma que os consumidores do serviço (outras aplicações, por exemplo) possam utilizar suas funcionalidades de forma prática. As definições e conceitos da SOA apontam para outro termo, tão importante e fundamental para as organizações quanto a SOA, a BPM (Business Process Management - Gestão de Processos de Negócios). Na verdade é a BPM que articula e orienta as funcionalidades da SOA para o mundo dos negócios. Para Weske (2007), a Gestão de Processos de Negócios (BPM) inclui conceitos, métodos e técnicas para apoiar o desenvolvimento, administração, configuração, representação e análise dos processos de negócios. Desta forma, pode-se afirmar que BPM combina a capacidade dos softwares, a inteligência das pessoas em negócios, sistemas e informações para acelerar o tempo entre as melhorias dos processos, facilitando a inovação dos negócios. Neste projeto, apresenta-se a implementação de um Protótipo da Arquitetura Orientada a Serviços na empresa Femepe Indústria e Comércio de Pescados SA para a ferramenta de Pedidos On-Line (desenvolvido em.net 2 ), ferramenta utilizada pelos Vendedores e Representantes da empresa para inclusão e acompanhamento de pedidos de venda. Por fim, é fundamental citar que são poucas as publicações nacionais como livros e artigos sobre o tema deste projeto de pesquisa. Assim, além de uma contribuição efetiva e real como modelo para os processos de negócios utilizando arquitetura orientada a serviço, este projeto também possibilita o incremento da literatura nacional sobre o tema abordado. 2 Plataforma única da Microsoft para desenvolvimento e execução de sistemas e aplicações. 3

17 1.1 PROBLEMATIZAÇÃO Formulação do Problema Neste século XXI, a evolução no mundo dos negócios é uma constante. Freqüentemente as organizações vêem a necessidade de mudanças nos processos de negócios e, conseqüentemente, nas ferramentas e sistemas que apóiam estes processos. A empresa Femepe Indústria e Comércio de Pescados SA possui uma ferramenta de Pedidos On-Line desenvolvida em.net, e esta necessita constantemente de evoluções principalmente no que competem as mudanças nos processos e regras de negócios (por exemplo, alteração no processo de aprovação de pedidos). A ferramenta foi desenvolvida através de implementações de funções e procedimentos, o que dificulta as alterações e as manutenções da mesma. A dificuldade ocorre, pois, o tempo para executar das alterações é curto e quando efetuadas as alterações é necessário efetuar a publicação das alterações, o que implica em parar temporariamente a ferramenta. Outra dificuldade é a integração com alguns parceiros de negócios (distribuidores, representantes) que já possuem sistemas e necessitam digitar os dados novamente na ferramenta de Pedidos On-Line, pois não há integração entre os sistemas, tornando o processo repetitivo Solução Proposta Este projeto visa solucionar a demanda das evoluções necessárias na ferramenta de Pedidos On-Line e na integração com parceiros que utilizam esta ferramenta, implementando os conceitos da arquitetura orientada a serviço. Assim, foram implementados serviços que atendam os processos e regras de negócios existentes, e que possibilite a inclusão de novos serviços e processos de negócios, de modo que utilizando técnicas de implementação de serviços fracamente acoplados, os serviços e processos tenham maior independência para evoluir, afetando o mínimo possível a estrutura geral da ferramenta. Estes serviços e processos de negócios são organizados e coordenados pela Gestão de Processos de Negócios (BPM) através do desenvolvimento de orquestração de serviços. 4

18 1.2 OBJETIVOS Objetivo Geral O objetivo geral deste trabalho foi a implementação e implantação de um protótipo da Arquitetura Orientada a Serviços (SOA) na empresa Femepe Indústria e Comércio de Pescados SA, visando otimizar os processos de negócios na ferramenta de Pedidos On-Line Objetivos Específicos Os objetivos específicos deste projeto de pesquisa que permitiram cumprir com o objetivo geral foram: 1. Pesquisar projetos similares que utilizam SOA; 2. Pesquisar e apresentar conceitos, características e tecnologias da Arquitetura Orientada a Serviços (SOA); 3. Pesquisar e apresentar os conceitos, tecnologias e padrões relacionados à BPM, BPEL e implementação de serviços (webservices); 4. Modelar processos de negócio e serviços; 5. Definir linguagem/ferramenta para implementação de serviços (webservices) e ferramenta para implementação dos processos de negócio (orquestração); 6. Implementar um protótipo de serviços (webservices); 7. Implementar um protótipo de processos de negócio (orquestração); 8. Testar e validar os processos de negócio e serviços; e 9. Implantar e validar o protótipo da SOA na empresa FEMEPE. 1.3 METODOLOGIA A metodologia utilizada para o desenvolvimento deste projeto possui as seguintes etapas: Etapa 1: Estudo. O objetivo dessa etapa foi pesquisar, analisar e apresentar os conceitos, características e tecnologias relacionadas à Arquitetura Orientada a Serviço e ao BPM. Etapa 2: Modelagem. O objetivo dessa etapa foi especificar e modelar serviços, processos de negócio e repositório de serviços para o funcionamento da Arquitetura Orientada a Serviço. 5

19 Etapa 3: Implementação. Nessa etapa foram implementados os Serviços, Processos de Negócio e Repositório de Serviços modelados. Etapa 4: Testes e Validação. Etapa na qual foram realizados os Testes e Validações dos serviços, processos de negócio e do repositório de serviços implementados. Etapa 5: Implantação. Nessa etapa ocorreu à implantação da Arquitetura SOA na empresa, integrando os Serviços e Processos de Negócio com a Ferramenta de Pedidos On-Line. 1.4 ESTRUTURA DO TRABALHO Este projeto está estruturado em 4 Capítulos: Introdução; Fundamentação Teórica; Desenvolvimento e Conclusão. O Capítulo 1, Introdução, oferece uma visão geral do projeto, apresentando um problema e a solução proposta, os objetivos do projeto e a metodologia utilizada. No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica abrangente sobre os conceitos, técnicas e características da Arquitetura Orientada a Serviço (SOA). Neste capítulo também é apresentado os conceitos e características da Gestão de Processos de Negócio (BPM), afim de relacionar tecnologias e negócios. São apresentados ainda 2 projetos similares a este. Por fim, são apresentadas as considerações gerais da fundamentação teórica. O Capítulo 3 apresenta o projeto detalhado da Arquitetura Orientada a Serviço, incluindo sua especificação, sua modelagem e sua implementação. Neste capítulo é descrito o Cenário Atual da Ferramenta de Pedidos On-Line, o Cenário Proposto e sua modelagem e a implementação dos Processos de Negócios, Serviços e Repositórios de Serviços. São apresentadas também as ferramentas utilizadas para a implementação. Ainda neste capítulo são apresentados os testes e validações dos Processos de Negócios e Serviços e a implantação da solução. Concluindo, no Capítulo 4, tem-se a conclusão do projeto, os objetivos alcançados e os trabalhos futuros a serem desenvolvidos no projeto. 6

20 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são apresentadas as informações necessárias para desenvolvimento e implementação da solução proposta, composta por: implementação e orquestração de serviços. Para tal, foram realizados estudos em livros, artigos, periódicos e sites da web. Na seção 2.1, são apresentados os conceitos e características relacionados a Arquitetura Orientada a Serviço e as tecnologias envolvidas no desenvolvimento e implementação desta arquitetura. Na seção 2.2, são apresentados os conceitos e as tecnologias relacionadas com a gestão de processos de negócios e orquestração de serviços. Na seção 2.3 são apresentados 2 projetos similares. 2.1 ARQUITETURA ORIENTADA A SERVIÇO (SOA) Esta seção apresenta conceitos, técnicas e características relacionadas à Arquitetura Orientada a Serviço. Inicialmente é conceituado serviço e SOA, posteriormente são apresentados os elementos e características da SOA. São apresentadas também as tecnologias necessárias para o desenvolvimento da SOA e são descritos informações necessárias para o desenvolvimento de Web Services seguros. Profissionais da área de TI, indústria de software e outros, se ocupam de um debate contínuo, interminável sobre o que é ou não é SOA. As pessoas identificam muitas das capacidades de SOA corretamente, mas, em grande parte não têm divulgado o conceito como um todo. Assim sendo, SOA, como o próprio nome diz, é uma arquitetura, um conjunto de padrões e princípios que englobam negócios e recursos tecnológicos. Diante disto, constata-se ainda mais, que a complexidade é um fato na vida da tecnologia da informação. Trabalha-se com a complexidade, quando, desenvolvem-se novas aplicações e substituem-se aplicações existentes. E também, mantendo o ritmo de todas as manutenções e solicitações de melhorias nas aplicações, o que representa o principal desafio da TI (NEWCOMER; LOMOW, 2004). Se todas as aplicações usassem uma interface de programação e protocolo de interoperabilidade comum, então o trabalho da TI seria muito mais simples, a complexidade seria reduzida e as funcionalidades existentes poderiam ser reutilizadas mais facilmente. Considerando uma interface de programação comum, onde, qualquer aplicação possa ser acessada, a infraestrutura de TI existente poderia evoluir e até ser substituída facilmente, sem que as aplicações

21 sofressem impactos decorrentes destes processos. Esta é a promessa que o desenvolvimento orientado ao serviço traz para o mundo da TI, e quando preparados para utilizar SOA, os serviços também se tornarão a base para a criação de uma variedade de novas soluções estratégicas de forma mais fácil, incluindo: Integração rápida de aplicações; Automatização de processos de negócios; e Acessos múltiplos para aplicações, incluindo dispositivos fixos e móveis. Estas soluções de aplicações compostas estão ao alcance através da adoção de Web Services (serviços) e do poder de transformação da SOA. O WSDL (Web Services Description Language - Linguagem de descrição de serviços web), se tornou uma interface de programação padrão para acessar qualquer aplicação, e o SOAP (Simple Object Access Protocol Protocolo de acesso a objetos simples), se tornou um protocolo de interoperabilidade padrão para conectar qualquer aplicação a outra. Estes dois padrões são o grande início e seguidos por muitos serviços adicionais que definem segurança, transações, orquestração e gerenciamento de meta dados, para satisfazer as exigências adicionais das características dos negócios e qualidade de serviços (NEWCOMER; LOMOW, 2004). De modo geral, o padrão Web Services, é a melhor plataforma para desenvolver uma SOA, a próxima geração da tecnologia da informação. Os conceitos, características e tecnologias apresentadas nesta seção, são fundamentais para o desenvolvimento deste projeto, pois, contemplam as informações necessárias para aplicação das técnicas utilizadas na SOA Conceituando Serviço Quando se fala em SOA, logo se pensa em serviço, fato facilmente compreendido, sendo que é o principal componente da arquitetura orientada a serviço. Serviço pode ser visto sob duas perspectivas, a de negócios e a de sistemas. Para Newcomer e Lomow (2004), na perspectiva de negócio, serviços são ativos de sistemas que correspondem a atividades reais de negócio ou funções reconhecidas de negócios que podem ser acessados de acordo com as políticas que foram estabelecidas para os serviços. 8

22 As políticas de serviço definem o que ou quem está autorizado a acessar o serviço, quando e onde o serviço esta disponível, o custo de uso do serviço, segurança (privacidade, integridade), desempenho (tempo de resposta) e assim por diante. Sob a perspectiva de sistemas, (NEWCOMER;LOMOW, 2004) define: Serviços são de granularidade grossa, recursos de sistemas reutilizáveis que têm interfaces bem definidas e separam claramente a interface externa e acessível da implementação técnica dos serviços. Esta separação de interface e implementação serve para o desacoplamento entre o consumidor e o provedor do serviço, de forma que ambos possam evoluir independentemente, desde que o contrato de serviço mantenha-se inalterado. Ainda, segundo Sampaio (2006), um serviço é um componente que atende a uma função de negócio específica para seus clientes. Ele recebe requisições e as responde ocultando todo o detalhamento do seu processamento. Um serviço deve executar unidades completas de trabalho, e não devem depender do estado de outros componentes. Desta forma, verifica-se a importância de serem stateless, ou seja, sem armazenamento de estado de conversação (SAMPAIO, 2006). Isto aumenta significativamente sua reutilização. Para reter esta independência, os serviços encapsulam lógica dentro de um contexto distinto. Este contexto pode ser específico a uma tarefa de negócios, uma entidade de negócios ou algum outro agrupamento lógico. Passo do processo serviço serviço sub-processo processo serviço Figura 1. Serviços podem encapsular lógica sob várias formas. Fonte: Adaptado de Erl (2005). 9

23 Ao construir uma solução de automatização que consiste em serviços, cada serviço pode encapsular uma tarefa a ser executada como um passo individual em um processo composto por um conjunto de passos (ERL, 2005). A Figura 1 mostra como funciona este encapsulamento. Na Figura 1, é evidenciado que, um serviço pode fazer parte de outro serviço de maior abrangência ou executar uma tarefa distinta de forma individual. Esta flexibilidade torna a reusabilidade de código e de serviços muito grande, aumentando significativamente o desempenho quando ocorrem mudanças nos processos de negócio ou quando há necessidade de se utilizar apenas uma tarefa de todo o processo. Para exemplificar esta situação de forma sucinta, veja a Figura 2. Serviço Inserir Pedido Serviço Consultar Clientes Consumindo serviço Aplicação frontend - 2 Aplicação frontend - 1 Consumindo serviço Fluxo interno Consumindo outros serviços Serviço Política Comercial Serviço Política Financeira Serviço... Figura 2. Aplicações frontend consumindo serviços e serviços consumindo serviços. Na Figura 2, a Aplicação frontend 1, esta consumindo o serviço Inserir Pedido, este por sua vez, possui um fluxo interno que reusa outros serviços, por exemplo, o serviço Consultar Clientes. A composição dos serviços demonstrada na Figura 2, possibilita que outra aplicação distinta, neste caso a Aplicação frontend 2, consuma um serviço já utilizado pelo serviço Inserir Pedido. Na SOA, os serviços podem ser usados por outros serviços ou por outras aplicações. A relação entre os serviços é baseada na forma como eles interagem. Esta interação é alcançada pelo uso de descrições de serviço (ERL, 2005). A descrição de serviço em seu formato mais básico, estabelece o nome do serviço e os dados esperados e devolvidos pelo serviço. Conforme Erl (2005), a maneira como os serviços utilizam os resultados das descrições de serviços esta classificada como uma relação fracamente acoplada, ou seja, eles devem ter a menor 10

24 dependência um do outro. Assim, os serviços não devem ser específicos para um problema, podendo ser utilizados por outros serviços distintos, outros processos ou como visto na Figura 2 por outras aplicações. Paralelamente a esta relação entre os serviços, ocorre à comunicação entre os mesmos, ou seja, a troca de mensagens. Após enviar uma mensagem, o serviço perde o controle sobre a mesma. Isto ocorre, devido ao fato de que mensagens e serviços devem ser autonômos. Desta forma, as mensagens devem ser providas de inteligência para controlar sua parte/ função na lógica do processo. Serviços que fornecem descrições de serviços e comunicação por troca de mensagens formam uma arquitetura básica. Esta arquitetura é semelhante às arquiteturas distribuídas do passado, que se apoiavam na troca de mensagens e na separação da interface, do processo lógico. O que distingue esta arquitetura, é, como os três componentes principais (serviços, descrições e mensagens) são projetados (ERL, 2005). É neste ponto que entra a orientação ao serviço. A Figura 3 exibe a troca de mensagens entre serviços. Neste caso, o serviço A, tem conhecimento do serviço B pois, o serviço A tem controle da descrição do serviço B. Figura 3. Uma mensagem existe como uma unidade independente de comunicação. Fonte: Adaptado de Erl (2005). Para Erl (2005), o termo SOA, possui vários modelos abstratos de orientação ao serviço, antes mesmo da chegada dos Web services. Porém, nenhum avanço tecnológico foi tão significativo e próspero na SOA do que os Web services. 11

25 A próxima seção descreve as características chaves dos serviços, sendo, estas de fundamental importação para o desenvolvimento do projeto Características chaves dos Serviços Segundo Newcomer e Lomow (2004), as características chaves que deveriam entrar no desenvolvimento, implementação, e administração de serviços são: a) Fraco acoplamento O acoplamento de serviços é constituído por três classes: acoplamento de interface, acoplamento de tecnologia e acoplamento de processo. Acoplamento de interface: refere-se ao acoplamento entre o requerente de serviço (cliente) e o provedor de serviços. Este acoplamento mede as dependências que o provedor de serviços impõe ao cliente, quanto menor a dependência, mais fraco será o acoplamento. Acoplamento de tecnologia: mede até que ponto um serviço depende de uma tecnologia em particular, um produto, ou plataforma de desenvolvimento (sistemas operacionais, linguagens, servidores de aplicação, pacotes de aplicação e plataformas de middleware). Acoplamento de processo: mede até que ponto um serviço é amarrado a um processo de negócios em particular. De modo geral, um serviço não deveria ser amarrado a um único processo de negócio de forma que este processo poderia ser reusado por outros processos e aplicações diferentes. Outros detalhes sobre fraco acoplamento será verificado na seção

26 b) Contratos bem definidos Todo serviço deve possuir uma interface bem definida, chamada de contrato de serviço, que define de forma clara as funcionalidades do serviço e como este pode ser invocado. Neste contexto, a WSDL (Web Services Description Language Linguagem de descrição de serviços web), fornece a base para os contratos de serviços. Porém, um contrato de serviço vai além do que pode ser definido na WSDL. É importante que o contrato de serviço esteja bem definido e baseado no conhecimento do negócio e não simplesmente em função da implementação do serviço (NEWCOMER; LOMOW, 2004). Embora não sejam amplamente reconhecidos, contratos de serviço são geralmente mais valiosos que as implementações de serviço. Um contrato de serviço incorpora o conhecimento do negócio, é constituído das regras definidas entre as partes (cliente e provedor, parceiros de negócio), é a base para o compartilhamento e reuso do serviço. c) Significância ao serviço requerente Devem ser definidos serviços e contratos de serviços a um nível de abstração, para que o serviço requerente compreenda a essência do negócio. Deve-se usar um vocabulário orientado ao negócio, definindo um domínio para a entrada e saída de documentos dos serviços de negócio. Evitar expor detalhes técnicos, como estruturas internas ou rotinas do serviço requerente (NEWCOMER; LOMOW, 2004) Conceituando SOA Esta seção apresenta conceitos da Arquitetura Orientada a Serviço, afim de oferecer um entendimento geral para este novo modelo de desenvolvimento de aplicações. Segundo Newcomer e Lomow (2004), uma Arquitetura Orientada a Serviço (SOA) é um estilo de projeto que orienta todos os aspectos de criar e usar serviços de negócios durante seu ciclo de vida. Permite também que aplicações diferentes possam trocar dados e participar de processos de negócios, indiferente de quais sejam os sistemas operacionais ou linguagens de programação que estão por trás dessas aplicações. Ainda segundo Carter (2007), SOA é a aproximação das áreas de TI e de negócios, integrando negócios, reutilizando serviços e processos de negócios, através de recursos 13

27 tecnológicos. A SOA auxilia os negócios, inovando e assegurando que sistemas possam adaptar-se rapidamente, facilmente e economicamente, apoiando as necessidades dos negócios que mudam freqüentemente. Permite ainda flexibilizar os processos de negócios, fortalecendo a infra-estrutura de TI, reutilizando os investimentos e recursos já disponíveis. A Arquitetura Orientada ao Serviço (SOA), representa um novo e evoluído modelo para desenvolvimento de aplicações distribuídas. Os serviços são componentes distribuídos que fornecem interfaces bem definidas que processam e entregam mensagens XML (Extensible Markup Language Linguagem de Marcação Extensível). O desenvolvimento de soluções baseadas em serviços ultrapassa os limites organizacionais e departamentais. Um negócio com múltiplos sistemas e aplicações em plataformas diferentes, pode usar SOA para desenvolver uma solução de integração fracamente acoplada que executa um fluxo de trabalho unificado (HASAN; DURAN, 2006). Pode-se dizer ainda que, em muitos aspectos SOA é uma aplicação da arquitetura cliente/servidor sob uma nova visão. De forma análoga a arquitetura cliente/servidor, um consumidor de serviço (cliente) envia uma mensagem a um provedor de serviço (servidor) que envia uma resposta, podendo ser o retorno de uma requisição ou a confirmação de alguma ação, conforme a Figura 4. Figura 4. Visão simplificada da SOA A arquitetura orientada a serviço é suportada por três princípios básicos, como mostra a Figura 5. Primeiro, é necessário prover uma definição abstrata do serviço, inclusive os detalhes que permitem que qualquer um que queira usar o serviço, se conecte a ele de modo apropriado (WEERAWARANA et al., 2005). Provedores de serviços precisam publicar detalhes dos serviços de forma que os consumidores destes serviços possam localizá-los e entender o que eles fazem, e que também possam obter informações de como usá-los mais precisamente. 14

28 Terceiro, os consumidores de serviços precisam de algum modo encontrar os serviços que estão disponíveis e que satisfaçam suas necessidades. Também, fazer um trabalho de aproximação para bind/publish/find (conectar/publicar/encontrar) e devem também ser definidos padrões para administrar os serviços, como publicar, encontrar a informação e os detalhes específicos de como se conectar (WEERAWARANA et al., 2005). UDDI Busca Agência de Registro de Serviços Descoberta de Serviços Publicação Consumidor de Serviços (Cliente) Requisição Resposta Provedor de Serviços (Servidor) Figura 5. O Triângulo da SOA Fonte: Adaptado de Weerawarana et al. (2005) A Figura 5 demonstra a dinâmica para a localização, busca, publicação e utilização dos serviços, e segundo Weerawarana et al. (2005) e conforme os princípios citados anteriormente, o Triângulo da SOA é baseado em três entidades bem definidas na SOA: Provedor de Serviço: Entidade que fornece os serviços. Responsável pela publicação dos serviços e gerenciamento dos mesmos. Consumidor de Serviço: Entidade que utiliza os serviços. Realiza as consultas na agência de registro de serviços para descobrir as características, funcionalidades e localização dos serviços. Agência de Registro de Serviço: Entidade que controla e mantém os serviços disponíveis, suas funcionalidades, localização, protocolos utilizados e demais informações. O consumidor de serviços pode usar a UDDI (Universal Description, Discovery and Integration Integração e descoberta da descrição universal), para descobrir ou referenciar a descrição de um provedor de serviço. 15

29 Além dessas três entidades, a SOA é também baseada em quatro abstrações (elementos) fundamentais: aplicação frontend, serviço, repositório de serviço e barramento de serviço, veja a Figura 6. Embora a aplicação frontend seja a proprietária do processo de negócio, os serviços é que fornecem funcionalidades de negócios que aplicações frontend e outros serviços podem usar. Um serviço consiste em uma implementação que provê lógica de negócios e dados, um contrato de serviço que especifica as funcionalidades, uso e restrições por parte de um cliente (consumidor de serviço), e uma interface de serviço que fisicamente expõe as funcionalidades. O repositório de serviço armazena o serviço e contrata serviços individuais de uma SOA e o barramento de serviço faz a conexão entre a aplicação frontend e os serviços (KRAFZIG;BANKE; SLAMA, 2004). SOA Aplicação frontend Serviço Repositório de Serviço Barramento de Serviço Contrato Implementação Interface Lógica de Negócio Dados Figura 6. Serviços e aplicações frontend são os principais componentes da SOA. Fonte: Adaptado de Krafzig, Banke e Slama (2004). Verifica-se que, as aplicações frontend são elementos ativos da SOA, agregando valor aos usuários finais. Já os serviços fornecem a estrutura da SOA e podem permanecer inalterados, enquanto as aplicações frontend podem mudar mais frequentemente. Como conseqüência, as aplicações frontend têm um ciclo de vida mais curto do que os serviços, como mostra a Figura 7. Este fato, se deve, ao considerar-se que serviços são elementos fundamentais e de importância estratégica em uma SOA. 16

30 Dados / conteúdo Serviços Aplicação frontend Inovação tecnológica / produtos Tecnologia (tempo de vida) Anos Figura 7. O ciclo de vida estimado de dados, serviços, aplicações frontend e tecnologias são diferentes Fonte: Adaptado de Krafzig, Banke e Slama (2004). Esta seção apresentou os conceitos da Arquitetura Orientada a Serviço e demonstrou que o ciclo de vida dos serviços é maior do que das aplicações tradicionais Elementos fundamentais da Arquitetura Orientada a Serviço Nesta seção, são abordados os elementos fundamentais da arquitetura orientada a serviço: aplicações frontend, serviços, repositório de serviços e barramento de serviços Aplicações frontend De acordo com Krafzig, Banke e Slama (2004), aplicações frontend são players (jogadores) ativos de uma SOA. Elas iniciam e controlam toda a atividade dos sistemas. Existem diferentes tipos de aplicações frontend. Uma aplicação frontend pode ser uma interface gráfica para o usuário, como uma aplicação Web que interage diretamente com usuários finais. Porém, aplicações frontend não necessariamente têm que interagir diretamente com usuários finais. Pode ser um conjunto de programas ou processos automatizados que invocam funcionalidades ou são resultados de eventos específicos (KRAFZIG; BANKE; SLAMA, 2004). No entanto, é possível que uma aplicação frontend delegue muito de sua responsabilidade para um processo de negócio com um ou mais serviços. Mas, no final das contas é sempre a aplicação frontend que inicia o processo de negócio e recebe os resultados. 17

31 Serviços Na seção Conceituando Serviço, detalhou-se o conceito e as características de serviço. Porém, nesta sessão o objetivo é apresentá-lo com um dos elementos fundamentais da SOA. Um serviço é um componente de software e encapsula um alto nível de conceito de negócios. Segundo Krafzig, Banke e Slama (2004), ele consiste das seguintes partes: Contrato. O contrato de serviço fornece uma especificação informal do propósito, funcionalidade, restrições, e uso do serviço; Interface. As funcionalidades dos serviços ficam expostas através da interface, para que clientes possam se conectar ao serviço; Implementação. A implementação de serviço fornece a lógica de negócio exigida e os dados apropriados; Lógica de negócio. A lógica de negócio é encapsulada por um serviço e faz parte de sua implementação. Fica disponível através das interfaces de serviço; e Dados. Um serviço também pode incluir dados Repositório de serviço Um repositório de serviço provê facilidades para descobrir serviços e adquirir toda a informação para usar os serviços, particularmente se estes serviços devem ser descobertos fora da extensão funcional e temporal do projeto que os criou (KRAFZIG; BANKE; SLAMA, 2004). A maior parte das informações exigidas já faz parte do contrato de serviço, mas, o repositório de serviço pode fornecer informação adicional, como local físico, informação sobre o provedor, pessoas de contato, taxas de uso, restrições técnicas, informações de segurança e níveis de serviço disponíveis. Ainda segundo Krafzig, Banke e Slama (2004), os repositórios de serviço são usados também para propósitos dentro dos limites de uma única empresa. Os repositórios que são tipicamente usados para integração de serviços entre empresas que têm diferentes exigências em particular, são publicados na internet. Estas exigências podem incluir 18

32 informações legais (termos e condições de uso), estilo de apresentação, segurança e registro de usuários por exemplo. Krafzig, Banke e Slama (2004), sugerem que as seguintes informações/recursos estejam contidos em um repositório de serviço: Serviços, operações e argumentos solicitados, na forma de WSDL e definições de XML Schema; Proprietário do serviço. Em um projeto SOA, os proprietários podem operar no nível de negócios (responsável por questões e pedidos de mudança no nível funcional), nível de desenvolvimento (responsável por questões técnicas e pedidos de mudança e nível de operações (responsável por questões relacionadas a unir um serviço); Direitos de acesso, como informação sobre lista de controle de acesso e o mecanismo de segurança ou uma descrição do processo que deve ser seguido dentro do projeto, de forma que um novo sistema, possa utilizar um serviço em particular; Informação sobre o desempenho e escalabilidade do serviço, inclusive, tempos de resposta e limitações de processamento. Isto pode ser resumido, como parte de um modelo SLA (Service Leve Agreement Acordo de Nível de Serviço) genérico; e Propriedades transacionais do serviço e suas operações individuais. Isto inclui, informação de leitura/escrita/atualização de características e lógica associada Barramento de serviço Um barramento de serviço conecta todos os participantes de serviços da SOA e aplicações frontend entre si. Se dois participantes precisarem se comunicar por exemplo, se uma aplicação frontend precisar invocar uma funcionalidade de um serviço, então, o barramento de serviço, faz isto acontecer (KRAFZIG; BANKE; SLAMA, 2004). Segundo Krafzig, Banke e Slama (2004), as principais características de um barramento de serviço são: Conexidade: o propósito primário do barramento de serviço é interconectar os participantes de uma SOA. Fornecer meios que habilitam os participantes de uma 19

33 SOA, participantes de uma aplicação frontend e serviços a invocar funcionalidades de outros serviços. Heterogeneidade de tecnologia: o barramento de serviço tem que abranger uma variedade tecnologias diferentes. A realidade das empresas é caracterizada através de tecnologias heterogêneas. Como conseqüência, o barramento de serviço deve poder conectar participantes que tem como base linguagens de programação ou sistemas operacionais diferentes. Heterogeneidade de conceitos de comunicação: similar à heterogeneidade de tecnologias, o barramento de serviço também tem que abranger uma variedade de conceitos de comunicação diferentes. Devido às exigências de aplicações diferentes, o barramento de serviço tem que habilitar modos de comunicação diferentes. Serviços técnicos: embora o propósito principal do barramento de serviço é a comunicação, também têm que fornecer serviços técnicos como segurança e tratamento de mensagens ou transações. A próxima seção apresenta as características da Arquitetura Orientada a Serviço que suportam os elementos fundamentais da SOA Considerações sobre os Elementos da SOA Os elementos serviços e repositório de serviços apresentados na seção 2.1.3, são amplamente utilizados neste projeto. Os processos de negócios deste projeto que são modelados e implementados através da utilização de serviços e para publicar e armazenar as informações destes serviços foi desenvolvido um repositório de serviços. 20

34 2.1.4 Características da Arquitetura Orientada a Serviço Nesta seção são apresentadas as principais características da SOA, sendo estas indispensáveis para o bom desenvolvimento da Arquitetura Orientada a Serviço. Este projeto visa implementar o máximo possível destas características, possibilitando assim, um melhor aproveitamento dos serviços e processos de negócios e auxiliando cada vez mais nos negócios da empresa. A arquitetura orientada a serviço oferece muitas vantagens para o desenvolvimento de aplicações, decorrente de suas características. Entre as características destacam-se: a) Fraco acoplamento Esta característica é a mais importante, e significa que os serviços não devem possuir uma dependência um do outro. O fraco acoplamento é uma condição em que um serviço adquire conhecimento de outro serviço, mas, permanece independente do mesmo. Outro fator relevante desta característica é que não existem restrições quanto à plataforma e a linguagem de programação que podem ser utilizados, sendo que, é utilizado um protocolo independente de plataforma. Desta forma aumenta a flexibilidade no desenvolvimento do serviço, sendo a linguagem e a plataforma, baseadas apenas nas restrições do próprio serviço. Esta situação permite que softwares legados sejam incluídos dentro da SOA, expondo suas funcionalidades em interfaces de serviços. Para Erl (2005), a característica fraco acoplamento, suporta outras características importantes da orientação a serviços e está intimamente relacionada com as mesmas, que são os seguintes: A reusabilidade de serviço é suportada pelo fraco acoplamento, devido aos serviços não possuírem dependências com outros. Isto aumenta a disponibilidade para reuso do serviço. A composição é sustentada pelo fraco acoplamento, especialmente quando os serviços estão dinamicamente compostos. Os contratos de serviços são os responsáveis pelo fraco acoplamento entre os serviços, sendo que o contrato é a única informação necessária para os serviços interagirem. 21

35 b) Composição Um serviço pode representar uma variação lógica qualquer, incluindo outros serviços. A principal razão em implementar este princípio (composição), é assegurar que os serviços sejam projetados de forma que possam participar como membros efetivos de composições em outros serviços. É importante destacar que para realizar o seu trabalho, o serviço independe da participação em outros serviços (ERL, 2005). A Figura 8, exibe como a composição facilita a reusabilidade, interoperabilidade, composição e a relação dos serviços. Figura 8. A operação AtualizaTudo, encapsula uma composição de serviços. Fonte: Adaptado de Erl (2005). Na Figura 8, fica claro a composição de serviços, sendo que o serviço principal AtualizaTudo é composto pelos serviços AtualizaLogs, AtualizaHistorico e AtualizaConta. Porém cada serviço executa sua tarefa de forma individual e podem ainda, participar de outras composições. Segundo Erl (2005), uma extensão da SOA que destaca a composição de serviços é o conceito de orquestração, que é apresentado neste trabalho. Na orquestração, um processo orientado a serviço pode ser classificado como uma composição de serviços, e é controlado por um serviço pai que é composto de serviços participantes do processo. 22

36 c) Reusabilidade A orientação a serviço favorece a reusabilidade de todos os serviços, indiferentemente se há solicitação de reuso. Aplicando padrões nos projetos de serviços, para torná-los potencialmente reutilizáveis, as chances de absorver as solicitações futuras com menor esforço de desenvolvimento são maiores (ERL, 2005). Naturalmente, serviços reutilizáveis também reduzem a necessidade de criação de novos serviços, diminuindo assim o número de serviços menos reutilizáveis. Essa característica facilita todas as formas de reuso, inclusive de interoperabilidade entre aplicações e de composição. A lógica encapsulada pelas operações individuais dos serviços deve ser considerada reutilizável para representar um serviço reutilizável, conforme mostra a Figura 9. ObterConta Serviço Conta AutalizaConta AdicionaConta Aplicação / Serviço Figura 9. Um serviço reutilizável apresenta operações reutilizáveis Fonte: Adaptado de Erl (2005). A Figura 9 mostra que uma aplicação ou serviço pode utilizar uma operação de outro serviço, desde que a operação esteja disponível para utilização de terceiros. d) Alta granularidade Segundo Sampaio (2006), granularidade é uma característica que ajuda a medir a complexidade de um modelo de componentes. Quando se deseja usar um componente e para isto precisa-se trabalhar no nível de classes, o que é muito detalhado, diz-se que a granularidade do componente é muito fina, ou seja, desce em nível de classes. 23

37 Quando junta-se modelos de classes relacionadas para executar uma tarefa, pode-se encapsular componentes, responsáveis por instanciar as classes necessárias para executar determinada tarefa (SAMPAIO, 2006). Por exemplo, em um sistema de pedidos on-line ao invés de termos classes Clientes, Produtos, Pedido, pode-se criar um componente para gerenciar produtos, outro para cliente e um para pedidos e assim se oculta o modelo de classes. Então, diz-se que a granularidade dos componentes é grossa, ou seja, executam mais de uma função. SOA visa criar componentes de granularidade grossa, chamados serviços, que requerem baixo acoplamento com seus clientes (requerentes do serviço) (SAMPAIO, 2006). e) Autonomia A autonomia requer que o alcance da lógica exposta por um serviço, esteja dentro de um limite explícito. Isto permite ao serviço manter o controle de todo o seu processo. Elimina dependências de outros serviços, e fica liberado de relações que poderiam inibir seu desenvolvimento e evolução (ERL, 2005), como mostra a Figura 10. Serviço 1 Aplicação Em execução, o serviço tem controle sobre a aplicação fundamental da lógica. lógica limite Figura 10. Serviços autônomos têm controle sobre recursos fundamentais. Fonte: Adaptado de Erl (2005). Pode-se dizer ainda que, a característica autonomia, permite a um serviço evoluir independentemente, de tal forma, que a SOA na qual está inserido, não é influenciada, se tal evolução não pertencer ao escopo da mesma como mostra a Figura

38 f) Interoperabilidade A interoperabilidade é outra característica marcante da arquitetura orientada a serviço. Ela possibilita que um serviço possa se comunicar de forma transparente com outros serviços, aplicações ou sistemas, indiferente de sua linguagem de desenvolvimento ou plataforma. Assim, os serviços são implementados de forma padronizada, utilizando tecnologias disponíveis para um grande grupo de plataformas de software. O protocolo de comunicação mais utilizado para a troca de informações (mensagens) é o SOAP, utilizando tecnologias baseadas em XML. Estas são profundamente utilizadas neste projeto, visando desenvolver uma Arquitetura Orientada a Serviço dinâmica e escalável. A próxima seção apresenta as tecnologias utilizadas para o desenvolvimento da Arquitetura Orientada a Serviço, sendo que estas oferecem condições para que o desenvolvimento possua conformidade com as características da SOA, como por exemplo, desenvolvimento de serviços fracamente acoplados Tecnologias Esta seção apresenta as tecnologias necessárias para o desenvolvimento da SOA, porém, não tem por objetivo esgotar o seu conteúdo. As tecnologias apresentadas são: Web Services - tecnologia para desenvolvimento de serviços para web, XML tecnologia para desenvolvimento de documentos que trafegam nas trocas de mensagens, WSDL tecnologia para o desenvolvimento de de descrições de serviços (contratos de serviço), SOAP protocolo para troca de mensagens e UDDI tecnologia utilizada para publicação e descoberta de serviços. A tecnologia mais utilizada para desenvolver a Arquitetura Orientada a Serviços é a de Web Services, ou também chamado de serviços web. Porém, pode-se desenvolver SOA utilizando qualquer outra tecnologia. Entretanto, a tecnologia mais difundida e mais utilizada pelos desenvolvedores é Web Services. Segundo Sampaio (2006), pela sua natureza, a tecnologia Web Services favorece muito a criação de componentes fracamente acoplados de granularidade grossa, duas características fundamentais da SOA. 25

39 A seguir destacam-se as tecnologias envolvidas para o desenvolvimento da arquitetura orientada a serviço sob o contexto de Web Services Web Services Web Service é uma tecnologia que esta fundamentalmente mudando a indústria de software, fazendo o papel da TI ser mais estratégico dentro das empresas, e redefinindo a relação entre o fornecedor e o consumidor de software. Muitas vezes confunde-se Web Services como uma série de tecnologias divulgadas na rede, como ASP 3, JSP 4 e scripts CGI 5. Segundo a W3C 6 (2004), Web Service tem a seguinte definição: Um web service é um sistema de software projetado para suportar interações máquinamáquina interoperáveis sobre uma rede. O web service possui uma interface descrita em um formato passível de processamento pela máquina, especificamente Web Service Description Language (WSDL). Outros sistemas interagem com o web service da maneira definida na sua interface usando mensagens SOAP (Simple Object Access Protocol), tipicamente transportadas usando HTTP (HiperText Transfer Protocol) com serialização XML (extensible Markup Language) e em conjunto com outros padrões relacionados à web. Na Figura 11 é exibida uma arquitetura básica de web services que consiste em especificações (SOAP, WSDL, e UDDI) que suportam a interação do requerente (consumidor) do web service com o provedor do web service e a capacidade de descoberta da descrição do web service. O provedor publica uma descrição WSDL de seu web service e o requerente acessa a descrição usando UDDI ou outro tipo de registro de solicita a execução do web service do provedor enviando uma mensagem SOAP a ele (NEWCOMER; LOMOW, 2004). 3 Active Server Pages é uma estrutura de programação de scripts. 4 Java Server Pages tecnologia para desenvolvimento de aplicações Web. 5 Common Gateway Interface tecnologia que permite gerar páginas dinâmicas. 6 World Wide Web Consortium consórcio de empresas de tecnologias. 26

40 Figura 11. Arquitetura básica de web services. Fonte: Adaptado de Newcomer e Lomow (2004). Chatterjee e Webber (2003) citam ainda que, web service representa um novo paradigma arquitetural para aplicações. Web service implementa funcionalidades que estão disponíveis para outras aplicações (ou até mesmo para outros web services), via padrões de comunicação, interface de aplicação e protocolos. Uma aplicação pode usar as funcionalidades de um Web Service, simplesmente invocando este através da rede sem ter que se integrar a ele. Para melhor exemplificar web service, a Figura 12 descreve as diferenças arquiteturais entre aplicações monolíticas, integradas e aplicações baseadas em web services. Aplicação Funcionalidade A Funcionalidade B Funcionalidade C (a) Aplicação monolítica com integração das funcionalidades A,B e C. Funcionalidade A (web service A) Endereços URL Funcionalidade B (web service B) REDE Aplicação Cliente Funcionalidade C (web service C) (b) Aplicação Cliente invoca web services(funcionalidades) remotos (A,B e C). Figura 12. Diferenças entre (a) aplicação monolítica com integração de funcionalidades, e (b) aplicação distribuída usando funcionalidades baseadas em web services. Fonte: Adaptado de Chatterjee e Webber (2003). 27

41 Na Figura 12, percebe-se que uma aplicação monolítica restringe suas funcionalidades a sua própria utilização, já web services oferecem suas funcionalidades a outros serviços e aplicações. As funcionalidades fornecidas por um web service podem pertencer a uma variedade de categorias, incluindo: Funções, como uma rotina para calcular a raiz quadrada de um número; Dados, como buscar a quantidade de um objeto que um vendedor tem disponível para venda; e Processos de negócio, com aceitar um pedido para um produto, transportar a quantidade desejada e enviar uma fatura. Algumas das funcionalidades existentes em aplicações são difíceis de serem integradas em outras aplicações. Mas, quando estas funcionalidades são expostas como web services, estes podem ser fracamente acoplados, alcançando os benefícios de uma integração, mas sem incorrer das dificuldades disso. Mas, os web services desenvolveram-se fundamentalmente a partir do conceito das aplicações web e segundo Chatterjee e Webber (2003), web services desenvolvem-se e estendemse sobre o modelo de aplicação web. Aplicações web permitem a qualquer web browser acessar suas funcionalidades, com uma aplicação de interface com o usuário apresentada através do browser. Entretanto, os web services estão um passo a frente e permitem que qualquer aplicação cliente avalie e use suas funcionalidades. Na verdade, web services é uma evolução das aplicações web, como mostra a Figura

42 Figura 13. Evolução de Aplicações Web para Web Services. Fonte: Adaptado de Chatterjee e Webber (2003). Como verificado, os web services possibilitam o aumento da produtividade e expansibilidade, criando um alto valor agregado na utilização dos mesmos para o desenvolvimento de aplicações. Com base nisto, os benefícios oriundos da utilização de web services segundo Chatterjee e Webber (2003), estão bem claros, são eles: Desenvolvimento de aplicações com alto valor agregado por conta da utilização de web services próprios e de terceiros; Integração de dados e processos de negócio com clientes e parceiros de negócios que desejam seu domínio técnico ou funcionalidades; Reduzir ou eliminar muitos erros de sistemas complexos e aplicações monolíticas grandes; Simplificar a manutenção e a customização de aplicações, segmentando uma aplicação na aplicação cliente através do consumo de web services; e Significativamente reduz o time-to-market, ou seja, reduz o tempo para que a aplicação seja colocada em produção. Conclui-se que web service nada mais é do que a tecnologia utilizada para desenvolver e implementar serviços na arquitetura orientada a serviço, ou seja, pode-se dizer que web services são serviços e vice-versa, sob o contexto SOA. 29

43 Portanto, web services representam enormes oportunidades e desafios. As organizações terão que ultrapassar as barreiras impostas para que possam utilizar de todos os benefícios desta tecnologia, melhorando assim os seus processos de negócio Extensible Markup Language (XML) XML (Exstensible Markup Language Linguagem de Marcação Extensível) é um termo muito utilizado e comentado por toda a internet e é muito utilizado neste projeto para a geração de documentos que são enviados nas mensagens para troca de dados entre Web Services e entre Web Services e aplicações. Hunter et al. (2007) se refere a XML como, uma tecnologia que rapidamente vem amadurecendo com poderosas aplicações no mundo real, em particular para gerenciar, exibir e organizar dados. Segundo Chatterjee e Webber (2003), XML é um padrão de marcação de dados apoiado pelo World Wide Web Consortium (W3C), chamado também de, o formato universal para descrever estruturas de dados na web. A idéia de um formato universal para dados não é nova. Uma tentativa no passado foi encontrar formas para trocar informações entre sistemas e aplicações diferentes através da SGML (Standard Generalized Markup Language Linguagem Padrão de Marcações Genéricas) (HUNTER et al., 2007). A SGML foi projetada para ser um padrão de marcação de dados quaisquer, principalmente em sistemas que administravam documentos grandes. Segundo Hunter el al. (2007), quando as enormes quantias de documentos possuíam dados complexos, várias eram as considerações a serem levadas em conta, neste caso a SGML era muito complicado. Uma linguagem muito famosa baseada no trabalho da SGML é o HTML (HyperText Markup Language Linguagem de marcação de HiperTexto). HTML usa muito dos conceitos da SGML para prover uma linguagem de marcação universal para a exibição de informação através da unificação de pedaços diferentes de informação (HUNTER et al., 2007). Entretanto, SGML é uma linguagem complicada e não possibilita a troca de dados na web. Já, o HTML teve enorme êxito, porém esta limitada na sua extensão, ou seja, foi planejado para 30

44 exibir documentos em um browser. Assim, a SOA necessita de uma forte integração e interoperabilidade, características estas concebidas pela tecnologia de web services. Quando usado múltiplas tecnologias web services como base para uma arquitetura de integração, como mostrado na Figura 14, os dados são convertidos em um formato geral, entendido por todos (neste caso, XML) e são passadas mensagens em um formato padrão de uma extremidade a outra (NEWCOMER; LOMOW, 2004). Figura 14. Múltiplas tecnologias de web services. Fonte: Newcomer e Lomow (2004). Fica claro que cada extremidade é responsável por transformar seus dados nativos em dados XML ao enviar uma mensagem e por traduzir dados XML em seus dados nativos ao receber uma mensagem. Existem 2 termos relacionados à XML que merecem destaque, são eles, marcação e extensibilidade. Segundo Daum e Merten (2002), XML é uma linguagem de marcação um documento pode ser estruturado com a ajuda de elementos de marcação sintática, semelhante aos que são usados na HTML. Estes elementos de marcação são bem conhecidos e chamados de TAGS. O X de XML significa extensível, que significa mais ou menos que você pode introduzir suas próprias tags e atributos. É exatamente este o poder da XML (DAUM; MERTEN, 2002). Ou seja, pode-se criar para identificar e representar dados, por exemplo: 31

45 <numero_telefone> </numero_telefone> É exatamente com este objetivo que a XML foi desenvolvida, para utilizar esta marcação semântica, onde um documento pode ser autodescrito, representando assim uma infinidade de informações, podendo estas serem interpretadas indiferentemente da tecnologia da outra extremidade. XML Schema Definition Language (XSD) Segundo Erl (2004), o XSD (XML Schema Definition Language Linguagem de Definição do Esquema XML), é um abragente modelo de dados para documentos XML e especificação de um XML schema, e tem recebido um amplo apoio da indústria de software para suportar um XML moderno e tecnologias web services. A estrutura hierárquica de documentos XML pode ser definida formalmente criando um XSD schema e conseqüentemente um documento XML é considerada uma instância similar do esquema (ERL, 2005). Conforme Erl (2005), as regras fundamentais de representação de dados na tecnologia XML são relacionadas e fornecidas por XSD schemas, na qual, representam dados de acordo com seu tipo. Erl (2005) diz ainda que, como nos tipos de dados utilizadas em linguagens de programação, os XSD schemas provêem de um conjunto de tipos de dados não proprietários que representam a informação em instâncias de documentos XML. Figura 15. Um documento XSD schema. Fonte: Erl (2005). 32

46 A estrutura estabelecida dentro de um XSD schema, conforme Figura 15, contém uma série de regras e restrições, nas quais, documentos XML têm que obedecer e ainda serem validados por softwares analisadores de sentenças Web Services Description Language (WSDL) Este seção descreve a tecnologia WSDL (Web Services Description Language Linguagem de descrição de serviços web), que é uma linguagem baseado em documentos XML, utilizada para descrever Web services. A WSDL, é uma tecnologia padrão e essencial associado com projetos baseados em Web Services. SOAP é o formato de mensagem que todos entendem no mundo dos web services, já a WSDL é o que todo mundo usa para falar com outros serviços e aplicações e para saber o que eles podem fazer, ou seja, é um documento escrito em XML para descrever um serviço e definir como acessá-lo e quais as funções ou métodos estão disponíveis (WEERAWARANA et al., 2005). WSDL é um vocabulário XML para descrever os web services. Permite que desenvolvedores de serviços forneçam informações necessárias sobre o serviço, de forma que outros serviços e aplicações possam usá-las. Segundo Weerawarana et al. (2005), WSDL é projetado para ser altamente extensível e adaptável para permitir a descrição de serviços que usam tipos de sistemas diferentes (como XML Schema, RelaxNG, ou até JAVA) e serviços que se comunicam através de SOAP e vários outros protocolos, como RMI (Remote Method Invocation Método de Invocação Remota). Figura 16. Estrutura Sintática da WSDL. Fonte: Weerawarana et al. (2005). 33

47 A Figura 16, exibe uma simples estrutura de um documento WSDL, responsável por identificar a interface de um Web Service. O código WSDL apresentado nesta figura é um exemplo de como os Web Services são publicados através da UDDI Simple Object Access Protocol (SOAP) Devido ao surgimento de novas tecnologias e frameworks de desenvolvimento é possível uma maior integração entre aplicativos e serviços disponíveis na internet, tratando tarefas complexas através de serviços distribuídos (web services) que utilizam interfaces bem definidas e com acesso simples. É neste ponto que entra o SOAP (Simple Object Access Protocol Protocolo de acesso a objetos simples), que é um padrão para a troca de mensagens entre aplicações e web services, considerando que SOAP é uma tecnologia baseada em XML e HTTP. Segundo Cunha (2002): SOAP é um protocolo projetado para invocar aplicações remotas através de RPC (Remote Procedure Calls - Chamadas Remotas de Procedimento) ou trocas de mensagens, em um ambiente independente de plataforma e linguagem de programação. SOAP é, portanto, um padrão normalmente aceito para utilizar-se com Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de transporte (HTTP) padrões. A Figura 17 mostra como as mensagens são transmitidas através de um protocolo de transporte entre os web services. Figura 17. A rede lógica de web services. Fonte: Adaptado de Chatterjee e Webber (2003). Chatterjee e Webber (2003) citam ainda que, SOAP é um mecanismo (protocolo) de transporte para troca de mensagens entre aplicações e serviços descritos por interfaces WSDL (CHATTERJEE;WEBBER, 2003). 34

48 Conforme Cunha (2002), e exibido na Figura 18, uma mensagem SOAP consiste basicamente dos seguintes elementos: Envelope: Toda mensagem SOAP deve contê-lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação. Um estilo de codificação define como os dados são representados no documento XML. Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope. Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem. Figura 18. Estrutura de uma mensagem SOAP. Fonte: Cunha (2002). A Figura 18 apresenta uma mensagem SOAP como sendo um envelope que é enviado de uma aplicação para um serviço ou de um serviço para um serviço. 35

49 Universal Description, Discovery and Integration (UDDI) A UDDI (Universal Description, Discovery and Integration - Integração e descoberta da descrição universal), é um registro e um protocolo para publicar e descobrir serviços web (web services). Como web services são baseados em padrões abertos e plataformas independentes, possibilita o acesso a funcionalidades de outras empresas (CHATTERJEE;WEBBER, 2003). Segundo Microsoft (2007a): [...] serviços UDDI é um serviço da Web XML com base em padrões que permite aos desenvolvedores das empresas publicar, descobrir, compartilhar e reutilizar com eficiência os serviços da Web diretamente através de suas ferramentas de desenvolvimento e aplicativos corporativos. A UDDI fornece um registro ou índice compartilhado onde consumidores de serviço (clientes) podem procurar negócios e serviços, nas quais querem interagir. A UDDI oferece um modo padrão para descrever os negócios, categorizando sob várias formas, como localização geográfica e setores da indústria, para que os potenciais consumidores (clientes), os localizem baseado nas suas exigências particulares (WEERAWARANA et al., 2005). Um dos atributos chave da SOA é a habilidade de se conectar a um serviço, e a UDDI é um componente fundamental ativando este comportamento. Ao invés, de um consumidor de serviço (cliente) implementar um serviço particular em um local particular, pode usar a UDDI para localizar um serviço implementado e então recuperar o local do serviço para configurar o cliente dinamicamente (WEERAWARANA et al., 2005). Para melhor definir o conceito de UDDI, a Figura 19 descreve as semelhanças entre uma lista telefônica e registros UDDI. Localizando Negócios Nome do Negócio e Número do Telefone Conectando o Negócio usando o número de telefone (a) Lista Telefônica Localizando Negócios e Serviços Nome do Negócio Serviço e Descrição do Serviço Conectando o Negócio usando o Serviço (b) Registro UDDI Figura 19. A rede lógica de web services. Fonte: Adaptado de Chatterjee e Webber (2003). 36

50 A UDDI realmente exerce as funções de uma lista telefônica, ou seja, uma aplicação ou serviço executa a pesquisa de um serviço no registro UDDI, caso seja localizado, conecta-se a este registro Segurança Os problemas de segurança na Internet não são muito diferentes dos problemas de segurança enfrentados no dia a dia. Sempre há alguém querendo capturar as informações que trafegam pela internet, não necessariamente estas informações têm que envolver diretamente transações financeiras. Pode ser uma transação que envolva uma simples consulta do status de um pedido de venda. Mas, com o uso crescente de computadores e do acesso a Internet aumentou o número de transações eletrônicas e assim aumentou também o número de falhas descobertas nos sistemas de transações eletrônicas. Como o propósito principal deste projeto é disponibilizar serviços na Web, esta seção apresenta a especificação WS-Security que facilita o desenvolvimento de Web Services seguros. WS-Security (Web Services Security) Segundo Chatterjee e Webber (2003), WS-Security é uma especificação que unifica múltiplas tecnologias para prover segurança para Web Services, em um esforço para suportar interoperabilidade entre sistemas, independente da plataforma. Mais especificamente, WS-Security define um conjunto de extensões SOAP que podem ser usadas para implementar integridade e confidencialidade de uma mensagem. WS-Security é um modelo e especificação unificado para proteção de mensagem dentro do ambiente de um Web Service. WS-Security especifica meios pelos quais podem ser protegidos o cabeçalho, corpo, anexos ou outras partes de uma mensagem através da combinação de criptografia e assinaturas digitais (CHATTERJEE;WEBBER, 2003). A WS-Security é composta por um conjunto especificações que compõe uma arquitetura bem definida, que pode ser visualizada na Figura

51 Figura 20. Arquitetura do WS-Security Fonte: Weerawarana et al. (2005). Como verificado na Figura 20, uma mensagem SOAP encapsula o WS-Security e toda a sua arquitetura. Alves (2007) define cada um dos componentes de WS-Security da seguinte maneira: WS-Policy Permite que os Web Services especifiquem quais os requisitos de segurança necessários para que seja acessado. Em geral, são usados certificados digitais X.509; WS-Trust Define como devem ser estabelecidas as relações de confiança. Essas relações podem ser diretas ou através de brokers/negociadores; WS-Privacy Explica quais itens devem ser incluídos dentro das descrições do WS- Policy; WS-SecureConversation Descreve como deve ser o canal de comunicação entre Web Services para que haja confiabilidade na transmissão de mensagens. Em geral, usa-se o protocolo SSL; WS-Federation Descreve uma camada integradora de requisitos WS-Policy e as relações de confiança do WS-Trust; e WS-Authorization Identifica quais itens devem ser verificados no processo de autorização e autenticação de Web Services. A implementação destes padrões é feita através do uso do cabeçalho de uma mensagem SOAP. É possível enviar no cabeçalho as credenciais do usuário, ou seja, a identificação do usuário para que este possa consumir o Web Service. Mais especificamente esta informações são inseridas 38

52 no Envelope da mensagem SOAP que é o elemento raiz de um documento XML conforme apresentado na seção Nesta seção foram apresentados os conceitos e características de serviços e da SOA e as tecnologias necessárias para a implementação da Arquitetura Orientada a Serviço. Assim, esta seção fornece os requisitos técnicos necessários para o desenvolvimento do projeto apresentado na seção 3.2, bem como a especificação de WS-Security para o desenvolvimento de Web Services seguros. Mas, para tornar, todos estes conceitos usuais dentro do cenário da empresa é necessário o entendimento da Gestão de Processos de Negócios (BPM) que será apresentado na próxima seção. 2.2 Business Process Management (BPM) - Gestão de Processos de Negócios Nesta seção são apresentados os conceitos e características da Gestão de Processos de Negócios, a orquestração de serviços necessária para o desenvolvimento dos fluxos dos processos de negócios que foram implementados neste projeto e a linguagem padrão de orquestração BPEL. A extensa área que a Gestão de Processo de Negócios (BPM) abrange, é dividida entre duas comunidades: administração empresarial e tecnologia da informação (TI). Devido ao importante crescimento do papel dos sistemas de informação na realização de processos de negócios, um entendimento comum e de interação entre estas comunidades é essencial. Weske (2007) diz que, devido a pontos de vistas diferentes, a interação entre estas comunidades raramente não possui rupturas. Profissionais de administração empresarial tendem a considerar a TI na posição de subordinado na gestão de processo de negócios. Por outro lado, profissionais de TI freqüentemente consideram que objetivos de negócios e regras organizacionais como condições que não merecem muito pensamento, mas requerem nível apropriado de abstração. Mesmo com rupturas na interação e com as divergências de alguns pensamentos entre estas comunidades, o que fica evidente é que elas mais do que nunca estão interligadas e são componentes fundamentais do BPM Processos de Negócios Resumidamente, um processo de negócio consiste em um conjunto de atividades que são executadas em coordenação em um ambiente organizacional e técnico. Estas atividades realizam objetivos de negócios em conjunto. Cada processo de negócio é executado por uma única 39

53 organização, mas pode interagir com processos de negócios de outras organizações (WESKE, 2007). Segundo Newcomer e Lomow (2004), processos de negócios são atividades do mundo real que consiste em um conjunto de tarefas logicamente relacionadas, e quando executadas em uma seqüência apropriada e de acordo com as regras de negócios corretas produz um determinado resultado. A Figura 21 exibe um exemplo de processo de negócio, para abrir uma conta de cliente. Figura 21. Processo de negócio simples. Fonte: Adaptado de Newcomer e Lomow (2004). Na Figura 21 o processo para abertura de uma conta de cliente, possui alguns passos que compõe o que é chamado de workflow 7, este workflow obedece regras de negócio para que o processo seja concluído. Assim este projeto, é constituído de alguns workflows apresentados nas seções e que compõem os processos de negócio que foram implementados. Portanto, é necessário a aplicação dos conceitos de BPM para que estes processos agreguem mais valor na cadeia de processos da empresa. 7 Fluxo de trabalho. 40

54 2.2.2 Gestão de Processos (BPM) Está cada vez mais difícil gerenciar negócios, pois, o ambiente em que os mesmos se encontram torna-se dia a dia mais complexos, devido ao crescente número de relacionamento entre parceiros e clientes. As mudanças no mercado acontecem rapidamente e criam uma infra-estrutura de TI mais heterogênea. As organizações apostam nos seus processos de negócios, orientando-as no ambiente complexo em que se encontram. Mas, esta complexidade pode tornar estes processos desconexos. É muito comum porém, a administração da organização adaptar-se rapidamente as mudanças nos seus processos, mas, é possível que a TI não consiga o mesmo feito. Para auxiliar a TI a acompanhar a evolução do mundo dos negócios, há a Gestão de Processos. Segundo Dutra Junior (2005), a Gestão de Processos é a habilidade de se obter total visibilidade e controle de ponta-a-ponta sobre todas as etapas de uma transação que viaje por múltiplas aplicações, interaja com diversas pessoas, em uma ou mais companhias. A Gestão de Processos de Negócios (BPM) inclui conceitos, métodos e técnicas para apoiar o desenvolvimento, administração, configuração, representação e análise dos processos de negócios. A base da Gestão de Processos de Negócios, é a representação explícita dos processos de negócios com suas atividades, e restrições de execução entre elas. Uma vez definidos os processos de negócios, estes estão sujeitos a análise, melhoria e aprovação. Segundo Newcomer e Lomow (2004), os principais objetivos e benefícios de BPM são: Reduz os obstáculos entre as necessidades dos negócios e a TI, permitindo aos usuários de negócios modelarem os processos, tendo infra-estrutura fornecida pelo departamento de TI para executar e controlar estes processos de negócios; Aumenta a produtividade dos funcionários, e reduz custos operacionais, automatizando e agilizando processos de negócios; Aumento da agilidade e flexibilidade, separando a lógica do processo de outras regras de negócios e processos de negócios, representando de uma forma que é fácil de mudar, como alteração de requisitos de negócio; e 41

55 Reduz despesas e esforços com desenvolvimento, usando linguagem de programação de alto nível, que permite aos analistas de negócios e desenvolvedores a construir e atualizar rapidamente sistemas de TI, dentro de um problema particular. É evidente que sistemas de informação estão presentes em processos de negócios de uma forma ou outra. Porém, o que faz a Gestão de Processos de Negócios ser única, ímpar, é que separa a lógica do processo de negócio de outras regras de negócios. Esta situação contrasta com outras formas de desenvolvimento de sistemas, onde a lógica do processo de negócio é profundamente embutida no código da aplicação (NEWCOMER; LOMOW, 2004). Relacionado com a gestão de processos de negócios tem-se a modelagem dos processos, também conhecido como BPM (Business Process Model Modelo de Processos de Negócios). O Business Process Model (BPM), consiste em um conjunto de modelos de atividade e restrições de execução entre elas. Uma instância de um processo de negócio representa um caso concreto de um processo operacional de uma empresa, consistindo em instâncias de atividade. Cada processo de negócio atua como um diagrama para um conjunto de instâncias de processos de negócios, e cada modelo de atividade atua como um diagrama para um conjunto de instâncias de atividades (WESKE, 2007). Weske (2007) diz que, os modelos de processos de negócios são os principais instrumentos para implementação de processos de negócios. Esta implementação pode ser feita por regras organizacionais e políticas, mas também pode ser feito por um sistema, usando um sistema de gestão de processos de negócios (Business Process Management Systems - BPMS). Esta seção forneceu informações para que os processos de negócios que foram implementados neste projeto sejam bem definidos, separando assim a lógica dos processos de negócio de outras regras de negócio Business Process Management Systems (BPMS) Sistemas de Gestão de Processos de Negócios Enquanto BPM é um conceito que esta relacionado com as funções de definir, administrar, interagir, e executar processo de negócios, já o BPMS (Business Process Management Systems Sistemas de Gestão de Processos de Negócios), fornece a tecnologia para implementar uma ou mais das funções do BPM (NEWCOMER;LOMOW, 2004). 42

56 De acordo com Krafzig, Banke e Slama (2004), um BPMS fornece a plataforma técnica para o BPM realizar iniciativas de gerenciamento. Compreende de várias partes, incluindo um mecanismo de BPM, facilidade no acompanhamento de processos de negócios, ferramentas de desenvolvimento e simulação. A instalação de um BPMS pode incluir vários produtos ou componentes de software customizados. Segundo Weske (2007), um Sistema de Gestão de Processos de Negócios é um software genérico que é conduzido através de representações explícitas de processos para coordenar processos de negócios. Um BPMS completo tem que fazer muito mais do que apenas executar um processo. A Figura 22 mostrar componentes básicos de um BPMS. Figura 22. Componentes básicos de um BPMS. Fonte: Adaptado de Newcomer e Lomow (2004). Os componentes básicos de um Sistema de Gestão de Processos de Negócios possuem diversas características que permitem todo o gerenciamento do processo, conforme destacados na Tabela 1. 43

57 Tabela 1. Características dos componentes básicos do BPMS. Componente Características Modelagem do Processo Execução do Processo Monitoramento de Processo e Monitorando Atividade de Negócio Infra-estrutura Modelagem gráfica e técnica do processo de negócio Métricas de modelagem e monitoramento de negócios Desenvolvimento colaborativo e simulação do processo de negócio Analisador de negócio e gerador de relatório Administração de usuários e de políticas de segurança Mecanismo para processamento e regras de negócios Administrador de lista de trabalho, Escalonamento e manipulação de exceção Delegação de tarefas e agendador de tarefas, Colaboração de usuário-a-usuário Atividade de negócios que monitora e gerencia eventos Administração e monitoramento de processo de negócio Painéis pré-definidos Auditoria e controle de log de erros. Fonte: Adaptado de Newcomer e Lomow (2004). Integração com sistemas de gestão empresarial e com Web Services Processamento de transação e arquitetura baseada em web Integração com sistemas de segurança e conectividade a banco de dados Escalabilidade e balanceamento de carga Para controlar a Gestão de Processos de Negócio deste projeto é utilizada a tecnologia WWF (Windows Workflow Foundation) na ferramenta de desenvolvimento Microsoft Visual Studio 2008, conforme apresentado na seção Tecnologias utilizadas na Implementação Benefícios do uso combinado de BPM, SOA e Web Services Esta seção apresenta os benefícios da utilização conjunta dos conceitos e características de BPM, SOA e Web Services, sendo que BPM e Web Services. A maioria das organizações possui um cenário composto por diversas tecnologias. Tipicamente há numerosos silos de aplicações, nome dado devido à natureza das aplicações, de serem independentes e sem interações com outras. Possuindo interfaces gráficas do usuário, lógica do negócio e acesso ao banco de dados na mesma aplicação. Assim, torna-se difícil compartilhar informações entre aplicações devido às diferentes plataformas de tecnologia e modelos de dados (NEWCOMER; LOMOW, 2004). A Figura 23, exibe diferentes aplicações e tecnologias sem a utilização combinada de BPM, SOA e Web Services, o que dificulta a integração e a troca informações entre as aplicações. 44

58 Figura 23. Aplicações típicas. Fonte: Adaptado de Newcomer e Lomow (2004). Pode-se combinar BPM, SOA e Web Services no cenário da Figura 23, flexibilizando a integração entre as aplicações, reutilizando funcionalidades e código, alinhando processos de negócios. Para tal, é necessário introduzir uma camada de serviço e uma camada de processos de negócios. A camada de serviço, consiste em serviços de negócios que são ajustados ao domínio particular do negócio. Os serviços são reutilizáveis e portanto podem ser utilizados por negócios múltiplos. A plataforma de Web Services, permite definir a utilização dos serviços, independente da aplicação e das plataformas de tecnologia. Já a camada de processos de negócios monitoriza e coordena todas as atividades de negócio. A Figura 24, demonstra a combinação das camadas de tecnologia, aplicação, web services e processos de negócio, representando um exemplo da utilização da arquitetura orientada a serviço. Figura 24. SOA, BPM e Web Services. Fonte: Adaptado de Newcomer e Lomow (2004). 45

59 Como verificado, a Figura 24 mostra o alinhamento entre as camadas de processo de negócio e serviços, que combinadas formam uma estrutura base para a SOA Orquestração e Coreografia São apresentados nesta seção os conceitos de orquestração e coreografia, que são os definidores de fluxos de processos de uma organização (orquestração) ou entre organizações (coreografia). Segundo Peltz (2003), orquestração refere-se a um processo de negócio executável que pode interagir com web services. A orquestração descreve como os web services podem interagir no nível de mensagem, incluindo lógica de negócio e a ordem na execução das interações. Estas interações podem transpor aplicações e/ou organizações, e resulta em um longo processo transacional. Com orquestração, o processo é sempre controlado a partir da perspectiva de um grupo. Conforme Peltz (2003), a coreografia localiza a seqüência de mensagens que podem envolver múltiplos grupos e múltiplas fontes. Está associada com as trocas de mensagens públicas que acontecem entre múltiplos Web services. Os termos orquestração e coreografia são freqüentemente usados para descrever dois caminhos para composição de web services. Embora os dois termos se sobreponham um pouco, a WSO (Web Services Orchestration orquestração de Web services) se refere a compor web services para processos de negócio, enquanto que WSC (Web Services Coreography Coreografia de Web services) se refere a compor Web services para colaborações de negócios (NEWCOMER;LOMOW, 2004). Mais especificamente, a orquestração de Web services (WSO) é usada para definir serviços compostos e processos internos que reusam Web services existentes, utilizando um coordenador (um processo central). WSO também pode ser usada para suportar a preparação de troca de informações externas em WSC. Pode-se dizer então que, a WSO possibilita que um serviço seja composto por outros serviços, reutilizando e permitindo a interação destes serviços através de troca de mensagens coordenados por um processo central. Uma WSO define os serviços que compõem a orquestração e a ordem nas quais os serviços devem ser executados, em forma de fluxos. 46

60 A Figura 25 exibe uma exemplo simples de orquestração. Figura 25. Orquestração de Serviços. Fonte: Adaptado de Sampaio (2006). Segundo Sampaio (2006): A orquestração é composta por um fluxo de etapas, com verificações de pré e póscondições, e um coordenador, responsável por dar andamento ao fluxo. O cliente se comunica com o coordenador e efetua a macro-solicitação, e o coordenador inicia o fluxo, invocando e verificando todas as etapas necessárias. Cada etapa invoca um serviço, que é oferecido por um provedor. Assim, pode-se mudar a ordem em que as etapas são executadas, incluir novas etapas, mudar as condições, criar novos fluxos ou incluir novos serviços sem ter a necessidade de alterar o código dos serviços, ou seja, é a aplicação máxima dos conceitos de reusabilidade. Já, a coreografia de Web services (WSC) é usada para definir como múltiplos grupos colaboram de modo direto, como parte de alguma transação de negócios maior, trocando mensagens com parceiros de negócios e organizações externas (NEWCOMER;LOMOW, 2004). A coreografia não depende de um coordenador central. Mais exatamente, cada Web service envolvido na coreografia sabe precisamente quando executar suas operações e com quem interagir. Coreografia é um esforço concentrado em troca de mensagens entre processos de negócio públicos. Todos os participantes da coreografia precisam estar atentos ao processo de negócio, a execução das operações, as trocas de mensagens, e ao tempo entre as trocas de mensagens (JURIC, 2006). 47

61 Em função desta descentralização, a coreografia é mais utilizada entre processos (WSO) ou Web services de organizações diferentes. Uma composição de Web services em coreografia é exibido na Figura 26. Figura 26. Coreografia de Serviços. Fonte: Adaptado de Juric (2006). Do ponto de vista de composição de Web services para executar processos de negócio, a orquestração tem uma vantagem sobre a coreografia. Orquestração é um paradigma mais flexível, embora as diferenças entre orquestração e coreografia esteja desaparecendo (JURIC, 2006). Segundo Juric (2006), orquestração tem as seguintes vantagens: Sabe-se exatamente quem é o responsável pela execução de todo o processo de negócio; Pode-se incorporar Web services, até mesmo os que não estão a par do processo, mas são uma parte do processo de negócio; e Pode-se também fornecer cenários alternativos quando ocorrem falhas. A Figura 27, mostra uma comparação entre orquestração e coreografia de Web services, com base na Figura 21, da seção

62 Requisição AbrirConta Recebe Coreografia de Web Services (Protocolos de Negócios) Buscar Informações da Conta Invocar Validar Informações da Conta Invocar Retorno Invocar Abrir Conta Reparar Informações da Conta Invocar Enviar Confirmação Invocar Pedido de Cona Recusado Figura 27. Comparação entre orquestração e coreografia de Web services. Fonte: Adaptado de Newcomer e Lomow (2004). Como se pode observar na Figura 27, a orquestração possibilita ao coordenador ter o total controle sobre todos os processos, já na coreografia não existe a figura de um coordenador sendo que o processo executado é seqüencial Business Process Execution Language (BPEL) Linguagem de Execução de Processos de Negócio A BPEL (Business Process Execution Language for Web Services Linguagem de Execução de Processos de Negócio), também conhecida como WS-BPEL ou BPEL4WS, é uma linguagem usada para desenvolver composição, orquestração, e coordenação de Web services. Fornece um rico vocabulário para expressar o comportamento dos processos de negócios (JURIC, 2006). A BPEL4WS foi concebida em julho de 2002, com a liberação da especificação BPEL4WS 1.0, um esforço conjunto entre IBM (International Business Machines), Microsoft e BEA Systems Inc. Este documento propôs uma linguagem de orquestração, como WSFL (Web Services Flow Language Linguagem de Fluxo de Web services) da IBM e a especificação XLANG da Microsoft (ERL, 2005). 49

63 Conforme Erl (2005), com a união de outros contribuintes SAP e Siebel Systems, a versão 1.1 da especificação BPEL4WS foi liberada menos de 1 ano depois, em maio de Esta versão recebeu mais atenção e apoio, conduzindo a vários mecanismos de orquestração compatíveis com BPEL4WS comercialmente disponíveis. Antes desta liberação, a especificação foi submetida ao comitê técnico OÁSIS, de forma que a especificação pudesse ser desenvolvida em um padrão aberto oficial. WS-BPEL é uma orientação a serviço que depende da WSDL. Um processo WS-BPEL pode ser exposto como um serviço definido por WSDL e pode ser invocado como qualquer outro Web service. Além disso, WS-BPEL considera que todo Web service externo esteja incluído em um composição de Web services, utilizando um contrato de serviço WSDL. Esta aproximação permite um processo de WS-BPEL invocar outro processo WS-BPEL e também permite um processo WS- BEPL chamar-se recursivamente (NEWCOMER; LOMOW, 2004). Figura 28. Definição de um processo WS-BPEL. Fonte: Erl (2005). A Figura 28, mostra a sintaxe em XML de uma definição comum de um processo WS- BPEL. Os processos definidos através de WS-BPEL pode ser utilizados em qualquer ferramenta que reconheça BPEL. Em geral a orquestração de um processo de negócio é desenvolvida utilizando uma ferramenta para modelagem de processos, mas, é importante conhecer a estrutura de um processo WS-BPEL, pois, talvez seja necessário efetuar uma manutenção no código para um refinamento do processo. 50

64 A BPEL é apontada como uma ferramenta importante no desenvolvimento e manutenção de aplicações, permitindo as empresas economizarem tempo e reduzirem custos, possibilitando assim, que as empresas se tornem mais ágeis e consigam adaptar-se rapidamente as mudanças nos negócios, um fato que ocorre com muito freqüência. Não só o fato das mudanças de negócios, mas também a necessidade de integração com parceiros de negócios, esta tornando necessário a utilização de serviços. Domínio (2006) cita o seguinte exemplo de orquestração utilizando BPEL: Uma empresa possui um processo de validação de crédito de clientes que realizam pedidos pela Internet, em seu site. A empresa trabalha com algumas empresas de proteção ao crédito, sendo que uma delas, oferece a resposta somente em vinte e quatro horas, após a requisição do cliente. Durante essas vinte e quatro horas iniciais, o pedido do cliente fica em validação de crédito. Após o recebimento da resposta, caso seja afirmativo, o processo deve continuar, enviando um para o cliente que o seu pedido de crédito foi aceito, informando também a provável data de entrega. O BPEL, orquestra essas requisições dando seqüência e gerenciando o andamento do processo, sejam eles internos ou externos, proveniente de outros serviços. Com BPEL é possível definir processos de negócio simples e complexos. Até certo ponto, BPEL é semelhante as linguagens de programação tradicionais. Possibilita desenvolver loops, desvios, variáveis e tarefas. Isso permite definir processos de negócio em forma algorítmica. BPEL é uma linguagem especializada e focalizada na definição de processos de negócio. Então, de um lado oferece desenvolvimento, que fazem a definição de processos de negócio relativamente simples. Por outro lado, é menos complexo que as linguagens de programação tradicionais, portanto simplifica a aprendizagem. O mais importante no desenvolvimento BPEL são as solicitações aos Web services. BPEL faz isto de forma fácil ao invocar atividades de Web services de forma síncrona ou assíncrona. É possível invocar atividades em seqüência ou em paralelo e aguardar um retorno. BPEL fornece um vocabulário rico para controlar falhas, o que é muito importante quando os processos de negócios são robustos, pois, é preciso reagir a falhas de modo inteligente (JURIC, 2006). Segundo Juric (2006) as principais características que BPEL provê são: Descreve a lógica de processos de negócios por composição de serviços e compõe grandes processos de negócios através de processos menores e serviços; 51

65 Controla solicitações síncrona e assíncronas de atividades de serviços, administra os retornos das atividades que ocorrerem no futuro e define a ordem em que elas são executadas; Invoca atividades de serviço em seqüência ou paralelo e retorna partes do processo quando as exceções ocorrem.; Define uma rota na entrada das mensagens para que as mesmas cheguem aos processos e atividades apropriados; Executa atividades em paralelo e define como unir fluxos paralelos baseado em condições de sincronização; e Envia mensagens XML para serviços remotos, manipula estrutura de dados XML e recebe mensagens XML assíncronas de serviços remotos; e Gerencia eventos e exceções. Figura 29. Orquestração de Web services com WS-BPEL. Fonte: Adaptado de Newcomer e Lomow (2004). A Figura 29, exibe uma orquestração de Web services utilizando WS-BPEL. É possível verificar que a WS-BPEL desenvolve um fluxo de processos, e de forma coordenada invoca os Web services através de mensagens SOAP. 52

66 2.3 PROJETOS SIMILARES Esta seção apresenta 2 projetos similares (relacionados) a este projeto, desenvolvidos com base na Arquitetura Orientada a Serviço. O primeiro projeto possui o título Roteiro para a definição de uma arquitetura SOA utilizando BPM e o segundo projeto possui o título Uma Arquitetura Orientada a Serviços para Desenvolvimento, Gerenciamento e Instalação de Serviços de Rede. A seguir são apresentados os projetos. Este projeto diferencia-se dos projetos similares apresentados a seguir, por demonstrar o desenvolvimento da Arquitetura Orientada a Serviços seus conceitos e técnicas em um cenário real, que impacta diretamente em processos de negócio de uma empresa. Primeiro Projeto: Roteiro para a definição de uma arquitetura SOA utilizando BPM Este projeto foi uma monografia apresentada por Benedete Junior (2007) à Escola Politécnica da Universidade de São Paulo para obtenção do Título de MBA em Tecnologia da Informação em O projeto propõe a utilização unificada da SOA e do BPM para auxiliar as empresas a produzirem melhores resultados, diminuírem os custos e desenvolverem produtos com um ciclo de vida mais curto e a terem um relacionamento mais personalizado e mais próximo de seus clientes. Propõe também que as empresas melhorem seus processos de negócio e sua comunicação com a área de TI. No projeto são abordados os conceitos, tecnologias, benefícios e ferramentas relacionadas a SOA e ao BPM, também é apresentado um ciclo de vida de melhoria de processos de negócio e um roteiro para sua implementação. Por fim, são apresentados os resultados da implementação do roteiro. Segundo Projeto: Uma Arquitetura Orientada a Serviços para Desenvolvimento, Gerenciamento e Instalação de Serviços de Rede Este projeto foi uma dissertação de mestrado apresentada por Souza (2006) à Faculdade de Engenharia Elétrica e de Computação da Universidade Estadual de Campinas como parte dos requisitos para obtenção do título de Mestre em Engenharia Elétrica em

67 O projeto apresenta uma abordagem da Arquitetura Orientada a Serviço para a implementação de redes que possam ser rapidamente instaladas, customizadas e gerenciadas por parte do cliente. Neste projeto os serviços de rede são elementos que interagem entre si e são implementados como Web Services. A lógica que executa o fluxo dos serviços de rede (Web Services) é definida através da orquestração destes Web Services. Neste projeto foram apresentados ainda dois serviços como estudo de caso para o gerenciamento de conexões de redes ópticas utilizando os conceitos e técnicas da SOANet (Service Oriented Architecture for Network Services). Segundo o autor deste projeto a A arquitetura SOANet tem por principal objetivo possibilitar o desenvolvimento rápido e flexível de novos serviços de rede. 2.4 CONSIDERAÇÕES DA FUNDAMENTAÇÃO TEÓRICA Este capítulo apresentou os conceitos, técnicas e tecnologias que estão inseridos no contexto da Arquitetura Orientada a Serviço. Evidenciou-se também o BPM, fundamental para o sucesso da SOA junto aos processos de negócios. Neste capítulo procurou-se demonstrar a importância das principais características da SOA: fraco acoplamento, composição, reusabilidade, alta granularidade, autonomia e interoperabilidade. Estas características têm dedicação especial no desenvolvimento do projeto, pois, a partir da prática destas características é possível desenvolver uma SOA sustentável. Ainda neste capítulo destacou-se a Gestão de Processos de Negócios, que neste projeto é importantíssima, sendo que, o objetivo final é possibilitar que a ferramenta de Pedidos On-Line seja mais dinâmica e escalável, tornando os processos de negócios mais flexíveis, para suportar de maneira fácil as mudanças e evoluções dos negócios da empresa. Finalmente, foram apresentados projetos similares, sendo estes diferenciados deste projeto. 54

68 3 DESENVOLVIMENTO Neste capítulo é apresentada uma breve modelagem do cenário atual da ferramenta de Pedidos On-Line e uma modelagem detalhada da solução proposta para a ferramenta de Pedidos On-Line. Também são apresentados os requisitos e regras de negócios que contemplam o escopo do desenvolvimento da SOA neste projeto. São apresentadas ainda neste capítulo as ferramentas utilizadas na implementação do projeto, a metodologia de implementação, as implementações dos Processos de Negócios, Web Services e Repositório de Serviços, os testes e validações e o processo de implantação do protótipo SOA na empresa. O objetivo deste projeto foi aplicar e desenvolver os conceitos e técnicas da Arquitetura Orientada a Serviço na ferramenta de Pedidos On-Line, para que a TI possa dar um melhor suporte as necessidades dos negócios da empresa, bem como se aproximar destes negócios. Não faz parte deste projeto desenvolver uma ferramenta de Pedidos, nem desenvolver interfaces gráficas (telas). Assim, é importante lembrar que todas as interfaces gráficas utilizadas no Cenário Atual (apresentado na próxima seção) são aproveitadas para o Cenário Proposto, por exemplo a tela de Inclusão de Pedidos exibida na Figura 72 do Apêndice A é utilizada pela Ferramenta de Pedidos On-Line e será reaproveitada. As interfaces utilizadas neste projeto constam no Apêndice A. Este capítulo é dividido em três macro seções. Na seção 3.1 é apresentado o Cenário Atual da ferramenta de Pedidos On-Line. Na seção 3.2 é apresentado o Cenário Proposto, aplicando os conceitos e técnicas da SOA. Na seção 3.3 é apresentada a implementação do Cenário Proposto, os testes e validações e o processo de implantação da SOA. 3.1 Cenário atual A ferramenta de Pedidos On-Line, também denominada Portal de Pedidos, é um importante recurso para os negócios da empresa. É através dela que cerca de 90% dos pedidos de venda dão entrada na empresa. Os pedidos são digitados na ferramenta por representantes, vendedores e gestores. Os representantes são empresas contratadas para vender os produtos, e através de um contrato de direito de representação estão autorizados a vender produtos de determinadas marcas comercializadas pela empresa em uma determinada região do país. Já os vendedores e gestores, são

69 funcionários da própria empresa que vendem todas as linhas de produtos nas regiões em que são contratados. Os vendedores especificamente têm a função de vender e gerenciar sua carteira de clientes. No caso dos gestores a responsabilidade é maior, estes têm que efetuar vendas para clientes de sua responsabilidade, gerenciar as atividades dos vendedores e fazer aprovações de pedidos de venda que estejam dentro de sua alçada. Assim, a força de vendas da empresa que é composta por 102 representantes, 12 vendedores 8 gestores estão sempre sujeitos às mudanças nos processos de negócio, sejam mudanças estruturais ou simples mudanças na política comercial. É neste ponto em que a ferramenta de Pedidos On-Line é fundamental, ela deve ser dinâmica, para que absorva rapidamente as mudanças, sem grande demora para implementação das alterações quando necessário. Mas, é justamente no momento em que há necessidade de mudanças em algum dos processos de negócio que se encontram as dificuldades, pois a ferramenta foi desenvolvida utilizando funções e procedimentos interligados. Desta forma, quando há necessidade de mudar um processo de negócio envolve-se boa parte do código, uma vez que as funções e procedimentos utilizados pela ferramenta são fortemente acoplados, ou seja, possuem forte dependência um do outro. Para entender melhor o funcionamento do Portal de Pedidos, a seguir será demonstrado os fluxos dos processos de negócios - pedidos e acompanhamento de pedidos da ferramenta de Pedidos On-Line. Fluxo geral do Processo de Negócio Pedidos O primeiro fluxo a ser demonstrado é o Processo de Negócio Pedidos. A Figura 30 mostra de forma simplificada todo o fluxo e os processos envolvidos. 56

70 Figura 30. Fluxo do Processo de Negócio - Pedidos. Como verificado na Figura 30, o Processo de Negócio - Pedidos é o processo macro, composto por 4 processos de negócio que se interligam: Digitação do Pedido, Análise Financeira, Análise Logística e Análise Comercial. Cada processo está ligado diretamente com o próximo processo do fluxo, criando assim grande dependência entre os processos, sendo que estes utilizam funções e procedimentos compartilhados, o que causa o forte acoplamento. A seguir, será demonstrado cada processo individualmente, identificando as telas em que cada um é utilizado na ferramenta de Pedidos On-Line e a ligação com os demais processos. Fluxo geral do Processo de Negócio - Digitação de Pedidos O Processo de Digitação do Pedido é o primeiro do fluxo, e a partir dele é iniciado todo o fluxo do processo de negócio pedidos. A Figura 31 exibe o Processo de Negócio Digitação do Pedido. 57

71 Processo de Negócio Digitação do Pedido Representante / Vendedor / Gestor TELA 01 Processo de Negócio Digitação do Pedido Enviado para o Processo de Análise Financeira Figura 31. Fluxo do Processo de Negócio - Digitação do Pedido. Para um melhor entendimento do processo de Digitação do Pedido, a Tabela 2 traz uma breve descrição do processo e da TELA 01 e seus relacionamentos com os outros processos de negócio. Tabela 2. Descrição do Processo de Negócio Digitação de Pedido. Tela/Processo TELA 01/Processo de Negócio Digitação do Pedido Descrição do Processo/Tela O Processo de Negócio - Digitação do Pedido, é utilizado pelos representantes, vendedores e gestores da empresa para inclusão de pedidos. O processo inicial do processo macro (Inclusão de Pedidos) é executado na TELA 01 (Figura 71 Apêndice A), e através dele é habilitado o próximo processo do fluxo que é o Processo de Análise Financeira. Desta forma, existe uma forte relação entre os procedimentos e funções (código fonte) dos Processos de Digitação do Pedido e Análise Financeira, o que gera um forte acoplamento, que dificulta a manutenção e a evolução individual de cada processo. Efetuada a digitação do Pedido de Venda, este fica sob aprovação financeira, iniciando assim o Processo de Negócio - Análise Financeira. Fluxo geral do Processo de Negócio Análise Financeira O Processo de Negócio Análise Financeira é responsável pela avaliação financeira do pedido, ou seja, é verificada a situação de crédito do cliente do pedido. Esta análise é executada pela interface exibida na Figura 73 do Apêndice A. A seguir, a Figura 32 demonstra este processo de negócio. 58

72 Figura 32. Fluxo do Processo de Negócio Análise Financeira. Como se constatou na Figura 32, a Análise Financeira é efetuada por um Analista Financeiro, ou seja, uma pessoa responsável por analisar o Pedido de Venda do ponto de vista financeiro. Na Tabela 3 consta uma descrição sucinta do processo. Tabela 3. Descrição do Processo de Negócio Análise Financeira. Tela/Processo TELA 02/Processo de Negócio Análise Financeira Descrição do Processo/Tela O Processo de Negócio Análise Financeira, é utilizado pelo Analista Financeiro para aprovar ou cancelar um pedido após sua avaliação financeira. Neste processo, o cancelamento do pedido depende da situação de crédito do cliente na empresa, em outras empresas ou no mercado financeiro. A TELA 02 é demonstrada na Figura 73 do Apêndice A. Fluxo geral do Processo de Negócio Análise Logística O Processo de Negócio Análise Logística é responsável pela avaliação logística do pedido, ou seja, é neste processo que é verificado se é possível atender um pedido do ponto de vista logístico, se há produto para ser entregue ou se o representante possui cota para este produto. A Figura 33 exibe o fluxo do Processo de Negócio Análise Logística detalhadamente. 59

73 Figura 33. Fluxo do Processo de Negócio Análise Logística. A Figura 33 demonstrou cada passo do Processo de Análise Logística, deixando claro que no cenário atual é muito complicado efetuar qualquer manutenção e ainda mais complicado é este processo sofrer uma evolução. Para descrever com mais detalhes o processo da Figura 33 é apresentada a Tabela 4. Tabela 4. Descrição do Processo de Negócio Análise Logística. Tela/Processo TELA 03/Processo de Negócio Análise Logística Descrição do Processo/Tela A TELA 03 é demonstrada na Figura 74 do Apêndice A. Esta interface é utilizada pelo Analista Logístico para aprovar ou não o pedido. É avaliado neste processo a cota do representante e o estoque dos produtos do pedido. 60

74 Fluxo geral do Processo de Negócio Análise Comercial O Processo de Negócio Análise Comercial é responsável pela avaliação comercial do pedido, ou seja, é neste processo que são analisados os preços, descontos e bonificações praticados no pedido de venda. A Figura 34 exibe o fluxo do Processo de Negócio Análise Comercial. Figura 34. Fluxo do Processo de Negócio Análise Comercial. A Figura 34 demonstra que o Processo de Negócio Análise Comercial é a última fase do Processo de Inclusão de Pedidos, sendo de responsabilidade dos gestores comerciais da empresa executar esta tarefa. O gestor que deverá aprovar o pedido é definido conforme sua alçada. A alçada está relacionada com o nível do gestor, obedecendo a seguinte ordem (da menor para a maior alçada): gestor regional, gestor nacional e gestor geral. A Tabela 3 apresenta a descrição do processo. Tabela 5. Descrição do Processo de Negócio Análise Comercial. Tela/Processo Descrição do Processo/Tela TELA 05/Processo de A TELA 05 é demonstrada na Figura 75 do Apêndice A. Esta interface Negócio Análise é utilizada pelo gestor comercial para aprovar ou não o pedido sob o Comercial ponto de vista comercial. 61

75 Fluxo geral do Processo de Negócio Acompanhamento de Pedidos O Processo de Negócio Acompanhamento de Pedidos permite ao usuário executar o acompanhamento do status do pedido, sendo de fundamental importância para o gerenciamento dos negócios. A Figura 35 exibe o fluxo deste processo. Processo de Negócios Acompanhamento de Pedidos Representante / Vendedor / Gestor TELA 06 Digitação do Parâmetros Executa a consulta de Acompanhamento de Pedidos TELA 07 Exibe uma consulta com a Lista de Pedidos (Acompanhamento de Pedidos) Figura 35. Fluxo do Processo de Negócio Acompanhamento de Pedidos. Este processo de negócio é muito importante tanto para a empresa quanto para os parceiros de negócio e, devido ao forte acoplamento entre os procedimentos e funções utilizados no seu desenvolvimento, dificultam a evolução e as alterações necessárias para este processo. A Tabela 6 apresenta a descrição do processo de Acompanhamento de Pedidos exibido na Figura 35. Tabela 6. Descrição do Processo de Negócio Acompanhamento de Pedidos. Tela/Processo TELA 06/Processo de Negócio Acompanhamento de Pedidos TELA 07/Processo de Negócio Acompanhamento de Pedidos Descrição do Processo/Tela A TELA 06 é demonstrada na Figura 76 do Apêndice A. Esta interface é utilizada pelo usuário para o preenchimento dos parâmetros que executam uma consulta de Acompanhamento de Pedidos. A TELA 07 é demonstrada na Figura 77 do Apêndice A. Esta interface é utilizada pelo usuário para verificar o status do pedido de venda e consultar a posição do Pedido. Esta seção apresentou os fluxos dos Processos de Negócio Pedidos e Acompanhamento de Pedidos utilizados atualmente na ferramenta de Pedidos On-Line, na qual foram identificados 62

76 alguns problemas, sendo que o principal é o forte acoplamento entre os procedimentos e funções utilizados no desenvolvimento da ferramenta. A próxima seção apresentará o Cenário Proposto que visa implementar a Arquitetura Orientada a Serviço para os Processos de Negócio Pedidos e Acompanhamento de Pedidos. 3.2 Cenário Proposto Como identificado na seção 3.1 Cenário atual, a ferramenta de Pedidos On-Line foi desenvolvida e modelada de forma que os procedimentos, funções e os processos de negócio estão interligados de tal maneira que dificulta a manutenção no código-fonte, dificulta também mudanças nos processos e nas regras de negócios, sendo que os componentes (procedimentos e funções) estão fortemente acoplados. Desta forma, impacta na demora por parte da equipe de TI em aplicar as alterações oriundas das manutenções na ferramenta, principalmente quando há mudanças nos processo de negócio, pois não existe uma independência entre os componentes (procedimentos e funções). Esta demora gera em alguns casos atraso na aplicação de novas regras de negócios que visam melhorar processos de negócio com parceiros e clientes, causando eventualmente perda de oportunidades de negócio. Assim, a proposta deste projeto é aplicar na ferramenta de Pedidos On-Line os conceitos e técnicas da Arquitetura Orientada a Serviço, apresentados na seção 2 FUNDAMENTAÇÃO TEÓRICA, tornando toda e qualquer alteração relacionada aos processos de inclusão e acompanhamento de pedidos mais dinâmica, ágil e confiável, fazendo com que a ferramenta de Pedidos On-Line seja mais escalável e agregue mais valor aos negócios da empresa. Também proporciona integrar a ferramenta de Pedidos On-Line com as aplicações dos parceiros de negócio (representantes). Nas próximas seções será apresentada a modelagem que substitui o cenário apresentado na seção 3.1 Cenário atual. 63

77 3.2.1 Modelagem do Processo de Negócio Pedidos Esta seção tem como objetivo apresentar uma solução para os problemas identificados no fluxo do Processo de Negócio Pedidos, utilizado atualmente na ferramenta de Pedidos On-Line, que foram apresentados na seção 3.1. Será apresentada a modelagem para o Processo de Negócio - Pedidos, que é o principal processo, sendo que os demais processos de negócio (Análise Financeira, Análise Logística e Análise Comercial) fazem parte deste processo. No cenário apresentado na seção 3.1, ficou evidenciado que os processos de negócio que compõe o processo de Pedidos, utilizados na ferramenta de Pedidos On-Line possuem forte acoplamento. Foi verificado também que a única maneira de incluir um pedido de venda é através da Figura 71 apresentada no Apêndice A. Como solução para estes problemas, é utilizada a SOA, seus conceitos e técnicas, com base no desenvolvimento de Web Services fracamente acoplados em substituição dos procedimentos e funções fortemente acoplados. Portanto, os processos citados anteriormente foram implementados através da tecnologia de Web Services, sendo que poderão ser invocados a partir de qualquer aplicação que suporte esta tecnologia, desde que tenham um contrato (ver seção ) para utilização destes Web Services. Com a utilização de Web Services fracamente acoplados é possível uma fácil manutenção nos processos de negócio, rapidez nas mudanças destes processos de forma confiável, devido a pouca ou nenhuma dependência de outros Web Services ou aplicações. A Figura 36 exibe uma visão geral da sistemática para inclusão de pedidos de venda utilizando SOA com Web Services para o Processo de Negócio Pedidos. Figura 36. Visão geral Processo de Negócio Pedidos. 64

78 Na Figura 36 é demonstrado que para a inclusão de um pedido no sistema da empresa, uma aplicação qualquer deverá consumir um Web Service, neste caso, o Web Service do Processo de Negócio Pedidos WS_PEDIDOS 8. Este é o processo central (processo mestre), sendo o responsável por coordenar todas as atividades do fluxo do processo e os demais processos, ou seja, é um Web Service coordenador. Ainda conforme a Figura 36, fica definido que uma aplicação/sistema da própria empresa, no caso a Ferramenta de Pedidos On-Line, ou de terceiros como, por exemplo, um sistema de pedidos de um representante, poderá consumir o Web Service WS_PEDIDOS. A Figura 37 demonstra de forma mais detalhada a utilização do Web Service sendo consumido por uma aplicação/sistema da própria empresa ou de terceiros, também chamada de aplicação cliente. Figura 37. Consumindo o WS_PEDIDOS através de troca de mensagens. Na Figura 37 são exibidos 3 passos para que a aplicação cliente efetue o envio do pedido de venda através de mensagens SOAP, utilizando uma string XML e, posteriormente, receba uma resposta se o pedido foi ou não validado. A Tabela 7 descreve os 3 passos. 8 Para um melhor entendimento os Web Services serão nomeados para facilitar a sua identificação quando forem citados no texto e serão precedidos por WS_. 65

79 Tabela 7. Consumindo o WS_PEDIDOS através de troca de mensagens XML. PASSO Requisição Resposta Ocorre a requisição de acesso a Caso ocorra o acesso a Aplicação/Sistema, é PASSO 1 Aplicação/Sistema para inclusão do possível a inclusão do pedido. Caso contrário pedido. exibe mensagem que não foi possível obter PASSO 2 PASSO 3 É executada uma chamada da aplicação/sistema para o Web Service WS_PEDIDOS. O WS_PEDIDOS identifica que a chamada foi apenas para troca de mensagens e invoca o serviço WS_VALIDACAO. acesso. Verifica se a aplicação/sistema requerente (cliente) possui permissão para acessar o Web Service. Caso possua um contrato (WSDL) a aplicação/sistema obtém acesso para utilizar o Web Service. Caso contrário, a requisição é interrompida informando que não possui permissão para acessar este Web Service. O WS_VALIDACAO valida os dados do pedido de venda enviado na mensagem SOAP utilizando uma string XML. Se o pedido for válido, então o WS_VALIDACAO invoca o próximo processo de negócio representado por um Web Service, que será apresentado mais adiante. Caso não seja validado, envia uma mensagem para a aplicação requerente, informando os motivos da não validação. A Tabela 7 descreve o WS_PEDIDOS recebendo uma mensagem XML contendo o pedido de venda. Assim sendo, o WS_PEDIDOS invoca o Web Service WS_VALIDACAO, que valida os dados da mensagem XML. É muito importante destacar que o Web Service WS_VALIDACAO é o responsável pela validação de informações, neste caso de informações do pedido de venda, mas também é utilizado para validar informações de outros Web Service ou processos como, por exemplo, validar informações dos parâmetros para o processo de acompanhamento de pedido. Esse Web Service é invocado em duas situações: Quando uma aplicação/sistema de terceiros desejar enviar um pedido; ou Quando for executado o botão SALVAR da Figura 71 do Apêndice A. 66

80 Assim, fica determinado que o processo que dará continuidade ao fluxo de inclusão de pedido é o WS_VALIDACAO, pois este sempre é invocado quando WS_PEDIDOS for consumido. Para uma melhor compreensão dessa situação, será abordada uma descrição de maneira mais técnica e simplificada. A Figura 38 demonstra esta comunicação técnica. Figura 38. Comunicação Aplicação/Sistema X Web Service e Web Service x Web Service. A Figura 38 exibe uma comunicação técnica e simplificada entre a ferramenta de Pedidos On-Line e Aplicação do representante com o Web Service WS_PEDIDOS. A seqüência na qual a comunicação ocorre tem os seguintes passos: PASSO 1: O usuário requisita acesso à aplicação/sistema para executar a inclusão ou alteração ou exclusão de pedido; PASSO 2: A ferramenta e/ou aplicação invoca o WS_PEDIDOS; PASSO 3: Se necessário é feita a localização e a identificação do Web Service utilizando o Repositório de Serviços. Através da UDDI (Universal Description, Discovery and Integration - Integração e descoberta da descrição universal) se obtém a localização do Web Service (poderia ser um Web Service publicado em outra organização ou em outro host da própria empresa). Com a WSDL (Web Services Description Language Linguagem de descrição de serviços web) se obtém a descrição do Web Service localizado; 67

81 PASSO 4: Após a localização e identificação do Web Service conclui-se a comunicação através do envio de uma mensagem SOAP com uma string XML, que contém as informações necessárias para esta comunicação, como identificação do requerente (cliente), permissões de acesso e os dados da mensagem (por exemplo, os dados do pedido caso a requisição seja de uma aplicação de terceiros); PASSO 5: Neste momento o processo já se encontra sob o domínio do Web Service Coordenador WS_PEDIDOS, que através da mensagem recebida identifica qual será o próximo passo do processo, que neste caso é consumir o Web Service WS_VALIDACAO. É importante destacar que é necessário utilizar a UDDI para localizar o Web Service desejado, caso o requerente (cliente) não saiba sua localização. Se souber, não há necessidade de localizar, mas poderá utilizar o repositório de serviços para obter a descrição do Web Service através da WSDL, pois a descrição de um Web Service pode ser alterado com freqüência, já a localização dificilmente se altera. Com a descrição técnica simplificada da Figura 38, fica definido o processo de comunicação entre aplicações e Web Service e de Web Services com Web Services, e este modelo servirá para as demais comunicações (trocas de mensagens) deste projeto. Esta seção destacou fundamentalmente que o Web Service WS_PEDIDOS pode ser utilizado (consumido) por uma aplicação da própria empresa ou de terceiros, o que aumenta significativamente a possibilidade de integração dos negócios da empresa com parceiros de negócio. Nas próximas seções serão apresentados os Web Services envolvidos no Processo de Negócio Pedidos Modelagem - Web Service WS_PEDIDOS Esta seção define a modelagem do Web Service WS_PEDIDOS e a composição deste por Web Services envolvidos no Processos de Negócio - Pedidos. Quando o Web Service for consumido por uma aplicação ou sistema, este pode ser invocado pela interface gráfica web da própria empresa que exibirá os campos para digitação do pedido, conforme Figura 71 do Apêndice A, ou receberá um pedido de uma aplicação de terceiros através de uma mensagem SOAP(XML), conforme verificado na seção

82 A Figura 39 apresenta uma visão geral do Web Service WS_PEDIDOS especificando os serviços que farão parte de sua composição, sendo que a composição é uma das características da SOA. Figura 39. Visão geral - Web Service WS_ PEDIDOS. Na Figura 39 fica claro o papel de Web Service principal (coordenador) que o WS_PEDIDOS assume. Assim, tem-se um Web Service coordenador, organizando o fluxo do processo e interagindo com os demais Web Services, caracterizando um cenário de orquestração apresentado na seção A Figura 39 também evidencia outra característica da SOA que é o fraco acoplamento. Os Web Services interagem apenas com o Web Service coordenador, não tendo dependência de outros Web Services. Os Web Services que compõe o Web Service WS_PEDIDOS estão descritos no Apêndice B e são os seguintes: WS_VALIDACAO, WS_ANALISE_FIN, WS_ANALISE_LOG, WS_ANALISE_CML e WS_ENVIA_ . Os Web Services WS_ANALISE_FIN, WS_ANALISE_LOG e WS_ANALISE_CML, substituem, respectivamente, os processos Análise Financeira, Análise Logística e Análise Comercial apresentados na seção 3.1. Assim, o Processo de Negócio - Pedidos executa uma seqüência de processos, por exemplo, Análise Financeira e Análise Logística, ou seja, constitui um workflow. Este workflow (fluxo de trabalho) destaca-se pela interoperabilidade entre o Web Service principal (coordenador) e os demais Web Services. É bom lembrar que interoperabilidade é uma das 69

83 características da SOA. Para melhor entender o funcionamento do Web Service WS_PEDIDOS a Figura 40 demonstra o workflow do Processo de Negócio Pedidos na qual este Web Service é o coordenador. Figura 40. Workflow - Web Service WS_PEDIDOS A Figura 40 mostra a interoperabilidade do Web Service WS_PEDIDOS com os demais Web Services, que define o processo de pedidos. A seqüência de passos exibidos na Figura 40 que compõe o workflow do WS_PEDIDOS é descrita a seguir: PASSO 1: WS_PEDIDOS é invocado por uma aplicação e recebe uma string XML (DadosXML), é identificado se esta possui um contrato (WSDL) para utilizar o serviço. Se possuir, WS_PEDIDOS invocará o Web Service WS_VALIDACAO; PASSO 2: WS_VALIDACAO é consumido por WS_PEDIDOS a partir do envio de uma string XML (DadosXML) com dados de um pedido, dados estes enviados de uma aplicação cliente da própria empresa ou de terceiros. Se os dados são inválidos, WS_PEDIDOS informa a aplicação requerente que os dados não são válidos e encerra o processo; 70

84 PASSO 3: Se os dados do pedido são válidos, então é invocado o Web Service WS_ANALISE_FIN; PASSO 4: Se os dados do pedido são válidos, então é invocado o Web Service WS_ANALISE_LOG; PASSO 5: Se os dados do pedido são válidos, então é invocado o Web Service WS_ANALISE_CML; e PASSO 6: Este passo ocorre quando WS_PEDIDOS tiver concluído o processo de validação, análise e inclusão/alteração/exclusão dos dados do pedido no banco de dados. Então, é enviado uma mensagem aos envolvidos no Processo de Negócio Pedidos através do Web Service WS_ENVIA_ . Nesta seção detalhou-se o Web Service WS_PEDIDOS e verificou-se a utilização de algumas características da SOA, como composição, interoperabilidade, fraco acoplamento e autonomia Integração Web Services e Ferramenta Pedidos On-Line Nesta seção é apresentada a integração dos Web Services desenvolvidos com a Ferramenta de Pedidos On-Line da empresa. A seqüência de passos a seguir demonstra a interoperabilidade (integração) dos Web Services com uma aplicação cliente, neste caso a Ferramenta de Pedidos On-Line da Própria empresa: PASSO 1: Para iniciar a utilização da rotina que integra os Web Services com a aplicação cliente é necessária abrir a tela de Pedidos confirme Figura 72, a partir deste momento inicia-se o preenchimento das informações do Pedido; PASSO 2: Para iniciar a digitação é necessário escolher um cliente, então ao clicar no botão (lupa) do campo Cliente, conforme a Figura 72 do Apêndice A, abre-se uma janela que é alimentada pelo Web Service WS_CLIENTE, onde se define o Cliente para o pedido; 71

85 PASSO 3: Ao clicar no botão (lupa) do campo Condição de Pagamento, conforme a Figura 72, abre-se uma janela que é alimentada pelo Web Service WS_CONDPG, onde se define uma Condição de Pagamento para o pedido; PASSO 4: Ao clicar no botão (lupa) do campo Produto, conforme a Figura 72 do Apêndice A, abre-se uma janela que é alimentada pelo Web Service WS_PRODUTOS, onde se define os produtos que farão parte do pedido; e PASSO 5: Ao clicar no botão SALVAR, conforme a Figura 72 do Apêndice A, é invocado o Web Service WS_PEDIDOS, que dará continuidade no processo de inclusão do pedido invocando o Web Service WS_VALIDACAO. A integração dos Web Services implementados também ocorre com o Processo de Negócio Acompanhamento de Pedidos, como pode ser verificado na Figura 76 e na Figura 77. Conclui-se desta forma que é possível integrar os Web Services implementados com qualquer aplicação que possui suporte a tecnologia de Web Services Modelagem - Web Service WS_VALIDACAO Nesta seção é definida a modelagem do Web Service WS_VALIDACAO, responsável por validar dados dentro do processo de pedidos. Sua função no processo de pedidos é fundamental, pois, todo e qualquer pedido passam por ele, seja um pedido enviado por uma aplicação de terceiros (representante) ou da própria empresa. O Web Service WS_VALIDACAO é composto pelos Web Services WS_CLIENTES, WS_CONDPG, WS_PRODUTOS, WS_TABPRECO e WS_VENDEDORES, descritos no Apêndice B. A Figura 41 demonstra o funcionamento do Web Service WS_VALIDACAO. 72

86 Requisição / Resposta DadosXML Figura 41. Workflow - Web Service WS_VALIDACAO A descrição da seqüência de passos do workflow do WS_VALIDACAO é a seguinte: PASSO 1: WS_VALIDACAO recebe uma mensagem SOAP contendo uma string XML (DadosXML); PASSO 2: WS_VALIDACAO valida os dados recebidos, invocando os Web Services pertinentes a cada informação que necessariamente deve ser validada. Neste caso invoca: WS_CONDPG (para validar a condição de pagamento do pedido), WS_PRODUTOS (para validar os produtos do pedido), WS_TABPRECO (para validar a tabela de preço), WS_CLIENTES (para validar as informações do cliente) e WS_VENDEDORES (para validar o vendedor do pedido; e PASSO 3: WS_VALIDACAO informa ao coordenador do processo (WS_PEDIDOS) se os dados foram ou não validados. O WS_VALIDACAO não validará apenas dados do Processo Pedidos, poderá validar também outras informações da Ferramenta de Pedidos On-Line, como as informações dos parâmetros de consulta do Processo de Acompanhamento de Pedidos. 73

87 Modelagem - Web Service WS_ANALISE_FIN Esta seção define a modelagem de um Web Service muito importante no Processo de Pedidos o Web Service WS_ANALISE_FIN, que executa o processo de Análise Financeira apresentado na seção 3.1 Cenário atual. A Figura 42 demonstra o workflow do Web Service WS_ANALISE_FIN. WS_PEDIDOS PASSO 1 Requisição / Resposta (DadosXML) PASSO 2 WS_ANALISE_FIN Figura 42. Workflow - Web Service WS_ANALISE_FIN Os passos executados no workflow da Figura 42 são descritos a seguir: PASSO 1: Se os dados do pedido são válidos, o Web Service WS_ANALISE_FIN recebe uma requisição através de uma mensagem contendo uma string XML (DadosXML) do Web Service WS_PEDIDOS contendo os dados do Pedido; e PASSO 2: Existem 2 situações em que o Web Service é invocando: a) Quando consumido pelo Web Service WS_PEDIDO, neste caso executa as Regras de Negócio e verifica as condições financeiras do pedido. Isto ocorre no momento da Inclusão/Alteração de um Pedido. Neste momento informa para WS_PEDIDO através de uma string XML o status da Análise Financeira, sendo que esta análise pode ou não bloquear o pedido no aspecto financeiro; b) O Web Service é invocado também durante a execução da interface gráfica exibida na Figura 73, que é utiliza pelo Analista Financeiro para liberar ou não um pedido bloqueado financeiramente. Ao clicar no botão Salvar da Figura 73, o Analista Financeiro grava a Aprovação Financeira conforme informações preenchidas na tela de análise, consumindo o WS_ANALISE_FIN. 74

88 A Análise Financeira executada pelo Web Service WS_ANALISE_FIN ocorre em dois momentos, na Inclusão/Alteração de um pedido de forma automática através das Regras de Negócio do serviço e na Aprovação Financeira que é executada pelo Analista Financeiro sempre que o Pedido for bloqueado pela análise na Inclusão/Alteração do pedido Modelagem - Web Service WS_ANALISE_LOG O Processo de Negócio Análise Logística verifica a situação logística do pedido, se o pedido pode ou não ser atendido, ou seja, se há estoque para os produtos solicitados no pedido. O Web Service responsável por este processo é o WS_ANALISE_LOG, que recebe do Web Service WS_PEDIDOS uma string XML (DadosXML), afim de executar a lógica desta Análise conforme demonstrado na seção 3.1. Assim o WS_ANALISE_LOG assume toda a complexidade do fluxo interno da Análise Logística, possibilitando que cada fase do Processo de Negócio Pedidos tenha independência desta complexidade, podendo ser alterado, evoluído e até excluído do processo, pois, o único Web Service que interage com WS_ANALISE_LOG é o Processo Principal (Coordenador) WS_PEDIDOS. Novamente caracteriza-se um cenário de fraco acoplamento. O Web Service WS_ANALISE_LOG é composto por Regras de Negócios definidas pela logística da empresa e pelo Web Service WS_COTA descrito no Apêndice B. A Figura 43 demonstra o workflow do Web Service WS_ANALISE_LOG. 75

89 WS_PEDIDOS PASSO 1 Requisição / Resposta (DadosXML) PASSO 2 WS_ANALISE_LOG Requisição / Resposta (DadosXML) PASSO 3 WS_COTA Figura 43. Workflow - Web Service WS_ANALISE_LOG Para assumir a complexidade da Análise Logística apresentada na seção 3.1, os passos do workflow da Figura 43 são descritos a seguir: PASSO 1: Se os dados do pedido são válidos, o Web Service WS_ANALISE_LOG recebe uma requisição através de uma mensagem contendo uma string XML (DadosXML) do Web Service WS_PEDIDOS contendo os dados do Pedido; PASSO 2: Existem 2 situações em que o Web Service é invocando: a) Quando consumido pelo Web Service WS_PEDIDO, neste caso executa as Regras de Negócio e verifica se há cota (quantidade do produto) disponível para o pedido em questão consumindo o Web Service WS_COTAS. Isto ocorre no momento da Inclusão/Alteração de um Pedido. Neste momento informa para WS_PEDIDO através de uma string XML o status da Análise Logística, sendo que esta análise pode ou não bloquear o pedido no aspecto logístico; b) O Web Service é invocado também durante a execução da interface gráfica exibida na Figura 74. Ao clicar no botão Salvar da Figura 74, o Analista Logístico grava a Aprovação Logística conforme informações preenchidas na tela de análise consumindo o WS_ANALISE_LOG; e PASSO 3: O Web Service WS_COTA recebe uma string XML (DadosXML) com as informações produto e quantidade e verifica a cota de venda disponível para este produto, após processar estas informações envia uma string XML (DadosXML) para o 76

90 WS_ANALISE_LOG. Detalhes sobre este Web Service podem ser verificados no Apêndice B. Assim, verifica-se que o Processo de Negócio Análise Logística facilmente pode ser adaptado e modificado conforme a necessidade e as regras de negócio da empresa, devido a utilização das características da SOA, reusabilidade, fraco acoplamento, interoperabilidade e autonomia Modelagem - Web Service WS_ANALISE_CML O Processo de Negócio Análise Comercial executa a análise comercial de um pedido de venda, ou seja, verifica se o pedido esta dentro da política comercial (preços, condição de pagamento, descontos). Este Processo é executado automaticamente quando invocado por WS_PEDIDOS ou manualmente por um gestor comercial. Existem 3 níveis de gestores: gestor regional, gestor nacional e gestor geral. Assim, a aprovação comercial é executada por um gestor conforme sua alçada, sendo esta definida nas regras de negócio da política comercial da empresa, que não faz parte do escopo deste projeto. Esta análise ocorre somente se o pedido não estiver dentro da política comercial da empresa. A Figura 44 demonstra o workflow do Web Service WS_ANALISE_CML. Figura 44. Workflow - Web Service WS_ANALISE_CML Os passos executados no workflow da Figura 44 são descritos a seguir: PASSO 1: Se os dados do pedido são válidos, o Web Service WS_ANALISE_CML recebe uma requisição através de uma mensagem contendo uma string XML (DadosXML) do Web Service WS_PEDIDOS contendo os dados do Pedido; e 77

91 PASSO 2: Existem 2 situações em que o Web Service é invocando: a) Quando consumido pelo Web Service WS_PEDIDO, neste caso executa as Regras de Negócio e verifica as condições comerciais do pedido. Isto ocorre no momento da Inclusão/Alteração de um Pedido. Neste momento informa para WS_PEDIDO o status da Análise Comercial, sendo que esta análise pode ou não bloquear o pedido no aspecto comercial; b) O Web Service é invocado também durante a execução da interface gráfica exibida na Figura 75, que é utiliza pelo Analise Comercial para liberar ou não um pedido bloqueado comercialmente. Ao clicar no botão Salvar da Figura 75, o Analista Comercial grava a Aprovação Comercial conforme informações preenchidas na tela de análise consumindo o WS_ANALISE_CML. A Análise Comercial executada pelo Web Service WS_ANALISE_CML é a última fase do Processo de Pedidos que também pode finalizar processo do pedido, caso o Gestor Comercial clique no botão Não Aprovar, conforme exibe a Figura 75 do Apêndice A. Se aprovar o pedido este ficará a disposição da importação do pedido para o sistema de gestão (ERP) da empresa, sendo que este processo de importação não faz parte do escopo deste projeto Modelagem do Processo de Negócio Acompanhamento de Pedidos Esta seção apresenta a modelagem do Processo de Negócio Acompanhamento de Pedidos, que é um processo de negócio simples, mas com alto valor agregado para a empresa e para os parceiros de negócio (representantes), sendo que possibilita fazer o acompanhamento do pedido de venda, disponibilizando o Status atual do pedido. Assim, é modelado o processo apresentado na seção 3.1, resolvendo os problemas de forte acoplamento, granularidade fina e reusabilidade, pois, da forma como este processo de negócio foi desenvolvido, através de funções e procedimentos, impossibilita a reusabilidade de código e componentes. Para resolver esses problemas, são aplicados a este processo de negócio os conceitos e técnicas da SOA. Este processo foi implementado com base no desenvolvimento de Web Services fracamente acoplados em substituição dos procedimentos e funções fortemente acoplados, já aplicados no Processo de Negócio Pedidos apresentado na seção A seguir, a Figura 45 demonstra o fluxo completo do Processo de Negócio Acompanhamento de Pedidos. O Web Service principal (coordenador) deste fluxo é o WS_ACMP_PEDIDOS, que tem a função de coordenar a orquestração deste processo de negócio. 78

92 Figura 45. Workflow - Web Service WS_ACMP_PEDIDOS Como o Processo de Negócio Acompanhamento de Pedidos é mais simples que o Processo de Negócios Pedidos, modelou-se todo o processo na Figura 45, para simplificar o entendimento. Portanto, os passos executados no workflow da Figura 45 são os seguintes: PASSO 1: WS_ACMP_PEDIDOS é invocado por uma Aplicação/Sistema cliente, e recebe uma string XML com os dados (DadosXML) da consulta de acompanhamento do Pedido; PASSO 2: WS_ACMP_PEDIDOS invoca WS_VALIDACAO para validar os dados da string XML (DadosXML) recebido da Aplicação cliente (própria ou de terceiros), sendo validado é enviado para o PASSO 3, caso contrário é devolvido para a Aplicação requerente um string XML informando que os dados não são válidos; PASSO 3: WS_ACMP_PEDIDOS processa uma string XML recebida da aplicação cliente, neste caso a aplicação da própria empresa exibida na Figura 76, e executa uma consulta conforme os parâmetros informados. A string XML é processada por WS_ACMP_PEDIDOS que gera outra string XML com as informações da consulta efetuada; e 79

93 PASSO 4: WS_ACMP_PEDIDOS envia essa string XML com os dados gerados pela consulta executada para a aplicação cliente. A seqüência de passos que são executadas, e que compõe o workflow do Processo de Negócio Acompanhamento de Pedidos, evidenciam que o Web Service WS_ACMP_PEDIDOS a exemplo do Web Service WS_PEDIDOS do Processo de Negócio Pedidos, também pode ser consumido de duas maneiras: a) por uma aplicação da própria empresa, por exemplo Ferramenta de Pedidos On-Line conforme Figura 76; ou b) por uma aplicação de terceiros, desde que esta envie a consulta através de uma string XML apresentada na seção Esta seção procurou destacar as principais etapas do Processo de Negócio Acompanhamento de Pedidos, sendo este um processo muito importante para os negócios da empresa, pois, tanto os colaboradores da empresa (vendedores e gestores) como parceiros de negócio (representantes) podem se beneficiar com este processo através de informações de suma importância Repositório de Serviços Esta seção visa demonstrar o funcionamento do Repositório de Serviços implementado para que os Web Services dos Processos de Negócios Pedidos e Acompanhamento de Pedidos sejam publicados e que, posteriormente, possam ser descobertos através da UDDI e identificados através da WSDL. A Figura 46 exibe o modelo deste repositório de serviço. 80

94 Figura 46. Repositório de Serviços para os Processos de Negócio Na Figura 46 são demonstrados os passos necessários para que uma aplicação possa descobrir, identificar e requisitar (invocar) um Web Service. Os passos são os seguintes: PASSO 1: O Provedor de Serviços, neste projeto a empresa, publica os Web Services em um repositório de serviços; PASSO 2: A aplicação requerente localiza e identifica o Web Service desejado; e PASSO 3: Após localizar e identificar o Web Service a aplicação requerente invoca o Web Service através das informações obtidas (URL, interface). O repositório de serviços é uma aplicação Web Service que contém a localização e identificação dos serviços fornecidos pelo provedor de serviços, neste caso a empresa do projeto. Assim, esta seção demonstrou o funcionamento do repositório de serviço para que as aplicações localizem e identifiquem os serviços e como estes são publicados Requisitos Esta seção procura descrever os requisitos necessários para a aplicação dos conceitos e técnicas da Arquitetura Orientada a Serviço neste projeto. Por não ser o escopo deste projeto, não são definidos requisitos para as funcionalidades e regras de negócio da Ferramenta de Pedidos On- Line, como por exemplo, definir um requisito funcional que determina que somente usuários cadastrados poderão usar a ferramenta ou uma regra negócio que determinada que um vendedor só poderá aplicar 9% de desconto em um pedido de venda. 81

95 Assim, os requisitos foram especificados para determinar as principais funções da Arquitetura Orientada a Serviços neste projeto, sendo que estas funções devem permitir aplicar os conceitos e técnicas da SOA. A seção de requisitos neste projeto, está posicionada depois da modelagem dos Processos de Negócio Pedidos e Acompanhamento de Pedidos para que possa ser melhor entendida, pois o objetivo do projeto não é o desenvolvimento de uma ferramenta e sim a aplicação de uma arquitetura, neste caso a SOA. Assim, não faria muito sentido que os requisitos estivessem antes da modelagem dos processos, pois não seriam facilmente compreendidos. As próximas seções apresentam as Regras de Negócio (RN), os Requisitos Funcionais (RF) e os Requisitos Não Funcionais (RNF) Regras de Negócio (RN) As regras de negócio apresentadas nesta seção têm como objetivo definir as políticas da implementação da Arquitetura Orientada a Serviços. As regras de negócio identificadas são as seguintes: RN01. Qualquer aplicação requerente deverá possuir um contrato (WSDL) bem definido para que possa utilizar os Processos de Negócio Pedidos e Acompanhamento de Pedidos e, conseqüentemente, seus Web Services; RN02. Apenas os Web Services publicados no repositório de serviços poderão ser consumidos; RN03. Nenhuma outra aplicação ou serviço fora do escopo do projeto poderá interferir nos Processos de Negócio Pedidos e Acompanhamento de Pedidos; e RN04. Os Web Services WS_PEDIDOS e WS_ACMP_PEDIDOS são os coordenadores dos Processos de Negócios, ou seja, os responsáveis pelo processo de orquestração Requisitos Funcionais (RF) Nesta seção são apresentados os requisitos funcionais que a Arquitetura Orientada a Serviço proposta na modelagem dos Processos de Negócio deverá contemplar, e são os seguintes: 82

96 RF01. A SOA deverá permitir que aplicações desktop da própria empresa possam consumir os Web Services, desde que possuam suporte a esta tecnologia; RF02. A SOA deverá permitir que aplicações Web tanto de terceiros como da própria empresa possam consumir os Web Services, desde que possuam suporte a esta tecnologia; RF03. A SOA deverá possuir um repositório de serviços; RF04. A SOA deverá permitir que os Web Services sejam descobertos (UDDI) e identificados (WSDL) em um repositório de serviços; e RF05. A SOA deverá permitir que um Web Service seja consumido por uma ou mais aplicações clientes simultaneamente Requisitos Não Funcionais (RNF) Os requisitos não funcionais apresentados nesta seção, descrevem as restrições da Arquitetura Orientada a Serviço proposta na modelagem dos processos de negócio. Os requisitos não funcionais são: RNF01. Os Web Services da SOA devem ser implementados de maneira que possam ser consumidos por qualquer aplicação requerente indiferente de sua plataforma, desde que esta aplicações possuam recursos para utilização de Web Services; RNF02. Os Web Services devem ser fracamente acoplados; RNF03. Os Web Services devem ser autônomos; RNF04. Os Web Services devem ser reusáveis; RNF05. O ambiente da SOA dever ser de alta granularidade; RNF06. A SOA deve caracterizar um cenário de composição; RNF07. A SOA será desenvolvida na plataforma.net, utilizando a linguagem C#; e RNF08. A ferramenta de desenvolvimento de Web Services e de orquestração será o Microsoft Visual Studio

97 3.3 IMPLEMENTAÇÃO Esta seção apresenta a implementação do Projeto modelado na seção Cenário Proposto, a metodologia de implementação, as tecnologias utilizadas para contemplar os conceitos da Arquitetura Orientada a Serviço para a implementação da SOA proposta, os testes e validações dos Processos de Negócios e Web Services implementados e o processo de implantação do Protótipo SOA. Porém, é apresentado de forma mais detalhada o desenvolvimento do principal Web Service modelado na seção Cenário Proposto, neste caso o Web Services WS_PEDIDOS, sendo que ele contempla toda a lógica da implementação deste projeto. São apresentadas também, as implementações dos Web Services WS_VALIDACAO, WS_ANALISE_FIN, WS_ANALISE_LOG, WS_ANALISE_CML e a implementação do Repositório de Serviços. Por fim, são apresentados os Testes e Validações dos Processos de Negócio e Web Services e o processo de implantação do Protótipo da SOA na empresa Metodologia e Tecnologias da Implementação A metodologia adotada neste projeto é a do Desenvolvimento em Camadas, ou ainda, decomposição em camadas e a do desenvolvimento de Orientação a Objetos. Na seção será apresentado o Desenvolvimento em Camadas, abordado durante o curso, mas por ser de fundamental importância para o entendimento do desenvolvimento deste projeto será evidenciado a seguir. Ainda neste projeto utiliza-se das definições e conceitos da metodologia de desenvolvimento de Orientação a Objetos, técnica essa abordada durante o curso de Ciência da Computação da Univali. As próximas seções apresentam a metodologia, as tecnologias e a estrutura de implementação do projeto e também o padrão de implementação dos Web Services Metodologia - Desenvolvimento em Camadas O desenvolvimento em camadas surgiu na década de 90, com inicio no desenvolvimento de aplicações cliente/servidor. Com o passar do tempo foi amadurecendo e chegou ao auge com o 84

98 desenvolvimento de aplicações Web, onde se faz necessário o desenvolvimento em camadas para se ter uma aplicação de qualidade com módulos fracamente acoplados. Segundo Microsoft (2007b): A decomposição de sistemas complexos em camadas é uma das técnicas mais utilizadas por arquitetos de software. A técnica foi emprestada da arquitetura de computadores, que utiliza camadas para chamadas de sistema operacional, device drivers, instruções do processador, até as portas lógicas contidas nos chips. Os protocolos de rede também têm utilizado a mesma técnica de camadas: por exemplo, o FTP é baseado em TCP, que por sua vez utiliza o protocolo IP, que utiliza Ethernet. Como motivação para a escolha da metodologia de Desenvolvimento em Camadas, verificou-se os seguintes benefícios: Pode-se entender uma camada com um todo, sem saber detalhes sobre as outras camadas. O que importa na relação entre as camadas é a interação, não importando como outra camada resolve determinada solicitação. Este benefício do desenvolvimento em camadas é uma das principais características da Arquitetura Orientada a Serviço, conhecida como Alta Granularidade; É possível substituir as camadas por outras implementações que contemplem as funcionalidades básicas das camadas; A dependência entre as camadas é reduzida, ou seja, fica evidenciado o fraco acoplamento entre as camadas, uma característica fundamental para o desenvolvimento de serviços; As camadas permitem definir padrões. O acesso a um banco de dados ou o desenvolvimento de regras de negócio podem ser padronizados em camadas; e As camadas podem ser reutilizadas por outras implementações, ou seja, pode-se ter uma camada sendo utilizada isoladamente por outra implementação, evidenciando assim duas características da SOA, a reusabilidade e o fraco acoplamento. O Desenvolvimento em Camadas divide-se em: Camada de Apresentação, Camada de Domínio/Negócio (Controle) e Camada de Dados. Segundo Microsoft (2007b), as responsabilidades das camadas são as seguintes: 85

99 Tabela 8. Descrição das Camadas. Camada Apresentação Negócio/Domínio (Controle) Dados Responsabilidades Provisionamento de serviços, exibição de informações. Lógica particular ao sistema. Comunicação com bancos de dados, sistemas de mensagens, monitores de transação. Conforme verificado na Tabela 8, cada camada possui responsabilidades específicas e devem ser desenvolvidas orientadas ao seu propósito de existência. Conforme Microsoft (2007b), pode-se ainda dizer que: Camada de Apresentação: executa a interação entre o usuário e o software, ou executa um sistema baseado em serviços web (Web Services). As responsabilidades primárias da camada de apresentação são interpretar as informações recebidas de um requerente (usuário ou sistema) para que as camadas de domínio e de dados e disponibilizem as informações processadas para o requerente; Camada de Negócio: também chamada de camada de controle, cuida das necessidades da aplicação no domínio em que ela se insere. Envolve cálculos baseados em dados recebidos e em informações armazenadas, validação de informações vindas da camada de apresentação, e qual fonte de dados devem ser acionadas, baseado em comandos recebidos; e Camada de Dados: cuida de toda interação com SGBDs e outras fontes de dados. Pode ser um monitor de transações, outras aplicações, sistemas de mensagens e assim por diante. Para a maior parte das aplicações corporativas, a fonte de dados é um banco de dados cuja responsabilidade é a persistência de dados não voláteis. Com a separação do desenvolvimento em camadas, surge uma regra importante em relação às dependências, as camadas de negócio e de dados jamais devem ser dependentes da camada de apresentação. Esta regra auxilia na utilização de diferentes camadas de apresentação para as mesmas camadas de negócio e dados. Já o relacionamento entre domínio de dados é mais complexo em função dos padrões de arquitetura utilizados para a camada de dados (MICROSOFT, 2007b). A seção a seguir demonstra como esta composta à estrutura de implementação do projeto, suas camadas e as principais classes para atender a solução proposta na seção

100 Tecnologias utilizadas na Implementação Esta seção descreve as tecnologias que utilizadas neste projeto para o desenvolvimento dos serviços e dos processos de negócio. A ferramenta utilizada neste projeto para implementação foi o Microsoft Visual Studio 2008 e a linguagem C#. Assim, a plataforma para desenvolvimento dos Web Services e dos Processos de Negócio foram.net framework 3.0 e 3.5 e as tecnologias WCF (Windows Communication Foundation) e WWF (Windows Workflow Foundation), incluídas no Microsoft Visual Studio Ainda na plataforma.net foi utilizada para acesso ao banco de dados a tecnologia LINQ (Language Integrated Query). Foi definida esta ferramenta por ser a utilizada pela empresa para o desenvolvimento dos projetos de software, sendo que o Delphi 2005 será descontinuado para futuros projetos. Neste projeto ainda foram utilizados o Microsoft Windows Server 2003 Enterprise Edition e o software de banco de dados Microsoft SQL Server 2000, necessários para o desenvolvimento do projeto. A seguir são descritos os recursos utilizados para o desenvolvimento deste projeto. Microsoft Visual Studio 2008 e C# O Microsoft Visual Studio 2008 é uma poderosa ferramenta para desenvolvimento de aplicações Web, aplicações distribuídas (SOA por exemplo), aplicações para dispositivos móveis ou aplicações smart client 9. Ela oferece diversas soluções e recursos para modelar, gerenciar, desenvolver e testar as aplicações, além de disponibilizar recursos que aperfeiçoam a produto do código fonte. O C# (cê charp) é uma linguagem de programação orientada a objetos que surgiu juntamente com a arquitetura.net. Um dos motivos para a escolha desta linguagem, é que a maioria das classes do.net Framework foram desenvolvidas em C#. Windows Communication Foundation (WCF) O Windows Communication Foundation (WCF) é uma nova tecnologia para o desenvolvimento de aplicações distribuídas (Web Services por exemplo). O WCF unifica um 9 Aplicativo do Cliente em um software Cliente/Servidor. 87

101 conjunto existente de tecnologias distribuídas.net, em um único modelo de programação (SKONNARD, 2007). O WCF fornece ao.net Framework uma base para escrever código que permita a comunicação entre componentes, aplicações e sistemas. Também foi projetado baseado nos princípios da orientação a serviço (SOA). O WCF utiliza mensagens para se comunicar. Estas mensagens são transferidas usando o protocolo SOAP. Assim, para o desenvolvimento de Web Services foi utilizado o Microsoft Visual Studio 2008, plataforma.net framework 3.0/3.5, linguagem C# e a tecnologia WCF para a comunicação e implementação dos Web Services. Windows Workflow Foundation (WWF) O Windows Workflow Foundation (WWF) é uma nova tecnologia da Microsoft utilizada para o desenvolvimento de workflows. Através do Microsoft Visual Studio 2008 é possível desenhar graficamente o workflow (BPM) de um processo de negócio utilizando o WWF. Assim, o fluxo de um conjunto de processos pode ser desenvolvido através WWF e posteriormente ser executado, seja este fluxo uma aplicação desktop ou uma aplicação Web. Portanto, pode-se desenhar o fluxo de um conjunto de Web Services através do WWF, mantendo o controle do fluxo do inicio ao fim do processo. Desta forma, para o desenvolvimento dos processos de negócios (BPM) deste projeto foi utilizado o Microsoft Visual Studio 2008, plataforma.net framework 3.0 e 3.5, linguagem C# e a tecnologia WWF para desenhar os workflows destes processos de negócio. Language Integrated Query (LINQ) O Language Integrated Query (LINQ) é uma tecnologia incluída no.net framework 3.5 e permite a manipulação de dados diretamente no banco. Permite ainda manipulação de dados em documentos XML, estrutura de dados, utilizando uma sintaxe similar a linguagem SQL. Microsoft Windows 2003 Enterprise Edition e Microsoft SQL Server 2000 O Microsoft Windows Server 2003 Enterprise é um sistema operacional da Microsoft que provê recursos e serviços que podem ser disponibilizados para aplicações cliente. 88

102 Foi utilizado neste projeto com duas finalidades específicas: 1) fornecer os serviços de hospedagem de páginas e serviços Web através do IIS (Internet Information Services Gerenciador de Informações da Internet), neste caso, fornecer os serviços de implementação e hospedagem do Site UDDI apresentado na seção ; e 2) fornecer os serviços do banco de dados SQL Server. O software de banco de dados Microsoft SQL Server 2000 foi utilizado para armazenar os dados do ERP da empresa e do Portal de Pedidos utilizados pelos Web Services implementados para inclusão, alteração, exclusão e consulta de dados Estrutura do Projeto A estrutura de desenvolvimento das camadas (apresentação, negócio e dados) do projeto e como estão compostas e as principais classes são apresentadas a seguir. A Figura 47 apresenta a janela do Solution Explorer da ferramenta Visual Studio, utilizada para o desenvolvimento do projeto, que contém a estrutura de implementação da solução do projeto, onde cada item é um Pacote pertencente à Solução. Por exemplo, Classes.ControleServico é um Pacote pertencente a Solução denominada Projeto SOA, e possui funcionalidades específicas que são abordadas mais adiante. Figura 47. Pacotes da Solução Janela Solution Explorer Visual Studio A Tabela 9 exibe a descrição dos Pacotes da Solução. 89

103 Tabela 9. Pacotes da Solução. Pacote Classes.Banco Classes.Biblioteca Classes.Controle Classes.ControleServico Classes.Excecoes Classes.InterfaceServico Classes.Modelo ServerHost ValidacaoWEB WebTestes Worklfow.Pedidos Workflow.Validacao Descrição do Pacote Pacote com as classes de acesso ao banco de dados. Pacote com as classes de bibliotecas auxiliares para manipulação de XML e métodos comuns de todas as classes. Pacote com as classes que contém a lógica, as regras de negócios dos Serviços visando à comunicação com o Banco de Dados. Pacote com as classes que contém a lógica, as regras de negócios específicas das funcionalidades do Serviço. Pacote com as classes que tratam exceções ocorridas no sistema. Pacote com as classes que disponibilizam as interfaces dos Serviços. Pacote com as Classes de modelo do banco de dados. Pacote que contém o Servidor de publicação dos Serviços. Pacote que contém Páginas implementadas para testes e validação dos Processos de Negócios, Serviços e Repositório de Serviços. Pacote utilizado para testar as implementações. Pacote que contém o Workflow (BPM) do Processo de Negócio Pedidos. Pacote que contém o Workflow (BPM) de validação de informações do pedido (inclusão/alteração/exclusão) e da consulta de pedidos. Para um melhor entendimento do funcionamento da solução, a Figura 48 exibe a distribuição dos pacotes da solução nas camadas as quais pertencem. WEB SERVICES (Classes.InterfaceServico) Classes.ControleServico Classes.Controle Classes.Biblioteca Workflow.Pedidos Workflow.Validacao Classes.Banco Classes.Modelo Figura 48. Camadas do Projeto e seus Pacotes Conforme exibido na Figura 48, os pacotes foram distribuídos de forma que as suas funcionalidades ficassem relacionadas a uma camada específica. 90

104 Padrão de Implementação Todo o projeto foi implementado através classes com métodos e procedimentos específicos para cada funcionalidade e todos os serviços foram implementados com as tecnologias de Web Services. A comunicação com os Web Services ocorre sempre com a troca de mensagens contendo uma string XML. A Figura 49 exibe de forma simplificada como funciona a comunicação entre uma Aplicação/Sistema e um Web Service do projeto. A Aplicação consome o Web Service enviando uma string XML, o Web Service processa esta string e envia para a aplicação cliente uma nova string XML com conteúdo específico referente o método executado. Figura 49. Comunicação entre Aplicação/Sistema com os Web Services Esta troca de mensagens contendo string XML pode ocorrer com Aplicações/Sistemas de terceiros ou da própria empresa. Na implementação da Arquitetura Orientada a Serviço deste projeto ocorre também a troca de mensagens entre Web Services, sendo que um Web Service consome outro Web Service enviando e recebendo uma string XML na troca de mensagens. 91

105 3.3.2 Implementação Web Service WS_PEDIDOS O WS_PEDIDOS é o Web Service responsável pela inclusão, manutenção e exclusão de pedidos. Nesta seção será demonstrado o processo utilizado no seu desenvolvimento, a integração entre as camadas, a integração do WS_PEDIDOS com os demais Web Services caracterizando assim o ambiente de orquestração. Este Web Service é responsável pela Inclusão, Alteração e Exclusão de Pedidos, ou seja, é o Web Service Coordenador do Processo de Negócio Pedidos, sendo responsável pela orquestração deste processo. A implementação deste Web Service será a mais detalhada por se tratar do principal Web Service deste projeto. Desta forma, poderá se ter uma visão mais completa do projeto, sendo que os demais Web Services seguem este padrão de implementação, não sendo necessário o seu detalhamento para evitar uma sobrecarga de informações. O WS_PEDIDOS possui a seguinte interface (camada de apresentação) exibida no código da Figura 50. [ServiceContract] public interface IWS_PEDIDOS { [OperationContract] string InclusaoPedido(string strxml); } [OperationContract] string AlteracaoPedido(string strxml); [OperationContract] string ExclusaoPedido(string strxml); Figura 50. Interface IWS_PEDIDOS Na Figura 50, o atributo [ServiceContract] define que IWS_PEDIDOS é uma interface que fornece um contrato de serviço, conforme apresentado na seção Características chaves dos Serviços (Contratos bem definidos). O atributo [OperationContract] define uma operação do contrato de serviço, ou seja, um método fornecido pelo serviço, que executa uma funcionalidade específica. A Tabela 10 exibe a descrição das funcionalidades dos métodos do serviço. 92

106 Tabela 10. Métodos do Web Service WS_PEDIDOS. Métodos InclusaoPedido AlteracaoPedido ExclusaoPedido Funcionalidade dos Métodos Tem a função executar a inclusão do pedido de venda. Neste método são executados os processos necessários para a inclusão (validação dos dados, análises). Tem a função executar a alteração do pedido de venda. Neste método são executados os processos necessários para a alteração (validação dos dados, análises). Tem a função executar a exclusão do pedido de venda. Neste método são executados os processos necessários para a exclusão. Em função de ser o principal Web Service desenvolvido neste projeto SOA, a Figura 51 exibe o fluxo geral do Web Service WS_PEDIDOS quando uma aplicação cliente consome o serviço através de um método, neste caso o método InclusaoPedido. Este detalhamento do Web Service WS_PEDIDO permite ter a visão completa de como os Web Services foram implementados, sendo que todos possuem a mesma estrutura como verificado anteriormente. DADOS NEGÓCIO CAMADAS APRESENTAÇÃO Figura 51. Comunicação das Classes do Web Service WS_PEDIDOS A Figura 51 exibe em passos a exata seqüência com que ocorre a comunicação entre os pacotes nas suas respectivas camadas, possibilitando assim, uma visão macro da troca de 93

107 informações entre os pacotes para atender a solicitação enviada para o Web Service. Segue breve explicação sobre cada passo de interação, utilizando como base o método InclusaoPedido: PASSO 1: a aplicação cliente consome o Web Service WS_PEDIDOS através do método string InclusaoPedido(string strxml) que recebe uma mensagem com uma string XML com os dados do pedido; PASSO 2: o pacote Classes.InterfaceServico que possui as interfaces dos serviços disponibilizados, neste caso IWS_PEDIDOS que é a interface que apresenta o Web Service WS_PEDIDOS para a aplicação cliente é implementado no pacote Classes.ControleServico na classe WS_PEDIDOS. O método InclusaoPedido da classe WS_PEDIDOS recebe a string XML enviada da aplicação cliente. Quando o processo voltar a este passo o método devolve para a interface IWS_PEDIDOS uma string XML; PASSO 3: no método InclusaoPedido da classe WS_PEDIDOS não há tratamento específico a ser feito na mensagem XML, então, instancia-se a classe PedidosCT do pacote Classes.Controle e envia-se a string XML para o método InclusaoPedido da classe PedidosCT. Quando o processo voltar a este passo o método da classe InclusaoPedido da classe PedidosCT devolve para classe WS_PEDIDOS uma string XML com as informações da inclusão ou não do pedido com os dados e/ou mensagens do processo de validação; PASSO 4: a classe PedidosCT do pacote Controle.Servico instancia a classe WFPedidos do pacote Workflow.Pedidos e inicia a execução do Workflow (fluxo) da inclusão do pedido enviando para WFPedidos a string XML com os dados do pedido. O Workflow da classe WFPedidos será apresentado mais adiante. Ao ser executado o Workflow pode seguir por dois caminhos. O primeiro é executar o passo 5, consumindo o Web Service WS_VALIDACAO e o segundo é executar o passo 6 enviando as informações já tratadas para a inserção no banco. O passo 6 é sempre executado depois do passo 5, sendo que é necessário ocorrer primeiro a validação das informações antes de os dados serem inseridos no banco; PASSO 5: a classe WFPedidos (Web Service WS_PEDIDOS) consome o Web Service WS_VALIDACAO que possui a implementação da classe WFValidacao do pacote Workflow.Validacao. O Web Service WS_VALIDACAO recebe uma string XML com 94

108 os dados do pedido, processa os dados e devolve outra string XML com o resultado da validação para o Web Service WS_PEDIDOS no ponto em que foi invocado na classe WFPedidos. Se os dados foram validados prossegue com o passo 6, caso contrário envia uma string XML para a classe PedidosCT contendo informações sobre a não validação dos dados. PedidosCT envia a string para a classe WS_PEDIDOS e através da interface (camada de apresentação) envia a string XML para a aplicação cliente; PASSO 6: a classe WFPedidos envia um conjunto de informações contendo os itens e o cabeçalho do pedido para a classe PedidoDB. O método InclusaoPedido da classe PedidosDB prepara os dados para enviar ao banco de dados. Ao voltar a este passo o método envia para a classe WFPedidos um tipo bool com o resultado da operação com o banco de dados, que ocorre no passo 7; PASSO 7: a classe PedidoDB executa a operação de inclusão do pedido no banco e se comunica implicitamente com a classes BancoDeDados que possui o modelo de dados, ou seja, possui a estrutura de dados e; e PASSO 8: toda a comunicação ocorrida até o passo 7 foi através de uma chamada de método ou Web Service, e a cada execução de um passo ocorre o retorno de um conjunto de dados, geralmente uma string XML que é tratada e transformada até chegar ao passo 8. Neste momento o Web Service WS_PEDIDOS envia para o aplicação cliente uma string XML contendo o resultado de todo o processo, se o pedido foi incluído ou não, se há bloqueio financeiro, logístico ou comercial, se incluído envia também os dados de cabeçalho e itens do pedido, se os dados do pedido não são válidos informa os motivos pela qual isto ocorreu. Como verificado nos passos descritos anteriormente, o fluxo deste Web Service esta centralizado no pacote Workflow.Pedidos (classe WFPedidos), ou seja, este Workflow controla efetivamente a maior parte do processo de negócio Pedidos, seja para a operação de inclusão, alteração ou exclusão de um pedido. É neste Workflow (WFPedidos) que estão inseridas as regras de negócios para as operações disponíveis pelo Web Service WS_PEDIDOS. Entenda-se por regras de negócios as validações que são executadas no Web Service WS_VALIDACAO (invocado pelo WFPedidos), as análises financeira, logística e comercial que 95

109 avaliam o pedido e são apresentadas mais adiante, enfim, a maior parte da lógica do fluxo do processo se encontram neste Workflow. É importante destacar que o Web Service WS_PEDIDOS é o coordenador de todo o processo, sendo o responsável por controlar o fluxo, invocar outros Web Services como WS_VALIDACAO, WS_ANALISE_FIN, WS_ANALISE_LOG, entre outros que são apresentados a seguir. Assim, este cenário se caracteriza como uma Orquestração Workflow WFPedidos Como já citado anteriormente o Workflow WFPedidos é o núcleo do Web Service WS_PEDIDOS, contendo as regras de negócios e a comunicação com outros Web Services pertencentes ao processo de Negócios de Pedidos (Inclusão, Alteração e Exclusão). A Figura 52 exibe o fluxo geral do Workflow WFPedidos implementado no Visual Studio com a tecnologia Windows Workflow Foundation (WWF), sendo possível visualizar o gerenciamento deste processo de negócio, evidenciando um cenário de BPM. Apesar da visão geral a Figura 52 apresenta os passos 1, 4 e 5 minimizados, indicado pelo ícone, sendo que nestes passos existem processos internos. 96

110 Figura 52. Workflow WFPedidos Os passos minimizados são apresentados a seguir com o detalhamento dos passos destacados no workflow. Este Workflow é instanciado e executado pela classe PedidosCT do pacote Classes.Controle como já verificado anteriormente. 97

111 PASSO 1 Neste passo é executado o bloco ValidacaoPedido, onde ocorre a validação dos dados do pedido. A Figura 53 exibe o processo utilizado para a validação dos dados do pedido. Este processo é fundamental para a continuidade da execução do Workflow. Figura 53. Workflow WFPedidos - ValidacaoPedido Como verificado na Figura 53, existem 2 objetos um denominado caseparadados e o outro cavalidacaopedido, objetos estes chamados de CodeActivity. Este objeto permite que o código de um procedimento ou função seja associado a ele. Pode-se verificar caseparadados e cavalidacaopedido são executados um após o outro nesta ordem. O procedimento executado por caseparadados tem a função de separar os dados do cabeçalho do pedido como, cliente, número do pedido, vendedor e os dados dos itens como produto, quantidade, valor e armazená-los para que sejam utilizados em outras etapas do Workflow. O procedimento executado por cavalidacaopedido invoca o Web Service WS_VALIDACAO (será apresentado mais adiante) passando como parâmetro a string XML recebida da aplicação cliente. Após o processamento o resultado da validação é armazenado em uma string XML com o resultado da validação. Esta string é analisada e alimenta uma variável (_bvalidacao) booleana com verdadeiro (true) se dados são válidos ou falso (false) caso os dados não sejam válidos. 98

112 PASSO 2 O passo 2 executa a verificação do resultado da validação analisando o valor armazenado na variável _bvalidacao alimentada no passo 1. Se _bvalidacao for true, então será executado o bloco Validou do Workflow, senão, será executado o bloco NaoValidou. Se o bloco NaoValidou for executado o próximo passo do Workflow será o passo 7. PASSO 3 Neste passo ocorre a verificação do Tipo de Operação que será executada, inclusão, alteração ou exclusão do pedido. No passo 1 foi executado o procedimento do objeto caseparadados, sendo que neste momento o Tipo de Operação enviado pela aplicação cliente alimentou um variável de controle (stroperacao) que é utilizada neste verificação. Se stroperacao for igual a INC (inclusão) ou ALT (alteração) executa o bloco INCLUSAO_ALTERACAO_PEDIDO, caso seja EXC (exclusão) executa o bloco EXCLUSAO_PEDIDO. O bloco EXCLUSAO_PEDIDO exclui o pedido enviado pela aplicação cliente, em seguida continua o Workflow executando o passo 6. PASSO 4 O passo 4 executa o bloco ExecutaAnalises. Este bloco é responsável por executar as análises financeira, logística e comercial. Para que isto ocorre são invocados os Web Services WS_ANALISE_FIN, WS_ANALISE_LOG e WS_ANALISE_CML. Estes Web Services são processos em paralelo obtendo assim informações sobre cada análise para que posteriormente estes dados sejam armazenados no banco de dados liberando o pedido ou aguardando por alguma liberação de algum dos gestores das áreas financeira, logística e comercial. Figura 54. Workflow WFPedidos ExecutaAnalises 99

113 A Figura 54 exibe o bloco ExecutaAnalises. Neste bloco existem 3 objetos CodeActivity, caanalise_fin que executa o Web Service WS_ANALISE_FIN, caanalise_log que executa o Web Service WS_ANALISE_LOG e caanalise_cml que executa o Web Service WS_ANALISE_CML. Cada procedimento executado resulta em uma string XML com a respectiva análise, estas informações são armazenadas para que sejam utilizadas no bloco GravaPedido. Informações sobre a implementação dos Web Services WS_ANALISE_FIN, WS_ANALISE_LOG e WS_ANALISE_CML são apresentados nas seções 3.3.4, e respectivamente. PASSO 5 Neste passo ocorre a execução do bloco GRAVAPEDIDO. Bloco este responsável por executar a gravação do pedido no banco de dados. A Figura 55 exibe os procedimentos executados para a gravação do pedido no banco de dados. Figura 55. Workflow WFPedidos GravaPedido O código executado em capreparadados reúne e ordena as informações necessárias para que o pedido seja gravado, como as informações das análises financeira, logística e comercial. Monta uma estrutura com o dados que são utilizados por cagravapedido. Em cagravapedido ocorre o procedimento para enviar os dados para o método InclusaoPedido da classes PedidosDB na camada Dados representada neste caso pelo pacote Classes.Banco. PASSO 6 Após o pedido ter sido incluído, alterado ou excluído é necessário o envio de um para os usuários diretamente relacionados com o pedido, neste caso o Gestor de Vendas e o vendedor. O 100

114 código caenvia se encarrega desta função invocando o Web Service WS_ que possui um método EnviaPedido com os parâmetros necessários para montar o para o envio. PASSO 7 Este passo finaliza o Workflow WFPedidos que contém todas as regras de negócio e todo o fluxo para executar uma operação de inclusão, alteração ou exclusão de um pedido. Portanto, o código do procedimento cafinalizaprocesso prepara um conjunto de informações com o resultado da operação executa e retorna para a classes PedidosCT que instanciou este Workflow uma string XML com todas as informações, sejam informações de inclusão, alteração ou exclusão do pedido, bem como informações sobre uma possível não validação dos dados representada no passo Estrutura string XML de Entrada e Saída Esta seção apresenta a estrutura da string XML recebida da aplicação cliente e a estrutura da string XML enviada para a aplicação cliente. A Figura 56 exibe estas estruturas XML processadas pelo Web Service WS_PEDIDOS quando são executados os métodos InclusaoPedido e AlteracaoPedido. 101

115 Figura 56. XML WS_PEDIDOS Para o melhor entendimento da Figura 56 a Tabela 11 (XML de entrada) e a Tabela 12 (XML de saída) apresentam os campos de cada XML. A Tabela 11 detalha a estrutura do XML de entrada recebido pela aplicação cliente informando os campos, os grupos a que estes campos pertencem dentro da string XML e as características do campo (tipo e tamanho). 102

116 Tabela 11. Estrutura XML de entrada WS_PEDIDOS. Grupo Campo Descrição Tipo Autenticacao Login Nome do usuário Caracter(10) Autenticação Senha Senha criptografada Caracter(1024) Cabeçalho Operação Descrição da Operação (INC Inclusão, ALT Alteração e EXC Caracter(03) Exclusão) Cabeçalho Cliente_Pedido Número de Pedido do Cliente Caracter(15) Cabeçalho Cliente_Cnpj Cnpj do Cliente Caracter(14) Cabeçalho Vendedor Código do Vendedor do Pedido Caracter(06) Cabeçalho Tabela_Preco Código da Tabela de Preço Caracter(03) Cabeçalho Cond_Pag Condição de Pagamento Caracter(03) Cabeçalho Data_Entrega Data de Entrega do Pedido Caracter(08) Itens/Item Produto Código do Produto Caracter(08) Itens/Item Quantidade Quantidade do Produto Numérico(4,0) Itens/Item Valor_Unitario Valor do Produto Numérico(10,2) Itens/Item Total_Item Valor total do Item Numérico(10,2) Itens/Item Perc_Desconto Percentual de Desconto Numérico(5,2) Itens/Item Preço_Desconto Valor do Produto com Desconto Numérico(10,2) Itens/Item Total_ItemDesconto Valor total do Item com Desconto Numérico(10,2) Itens/Item Tipo_Item Tipo do Item (P Pedido, B Bonificação) Caracter(01) A Tabela 12 apresenta o detalhamento das informações geradas pelo Web Service WS_PEDIDOS e que são enviadas para a aplicação cliente. Nesta tabela são informados os campos, os grupos a que estes campos pertencem dentro da string XML e as características do campo (tipo e tamanho). 103

117 Tabela 12. Estrutura XML de saída WS_PEDIDOS. Grupo Campo Descrição Tipo Cabeçalho Sistema_Pedido Número do Pedido do Sistema Caracter(06) Cabeçalho Cliente_Pedido Número de Pedido do Cliente Caracter(15) Cabeçalho Cliente_Cnpj Cnpj do Cliente Caracter(14) Cabeçalho Cliente_Nome Razão social do Cliente Caracter(100) Cabeçalho Cliente_End Endereço do Cliente Caracter(50) Cabeçalho Cliente_Bairro Bairro do Cliente Caracter(30) Cabeçalho Cliente_Cidade Cidade do Cliente Caracter(30) Cabeçalho Cliente_Uf Estado do Cliente Caracter(02) Cabeçalho Vendedor Código do Vendedor do Pedido Caracter(06) Cabeçalho Vendedor_Nome Nome do Vendedor Caracter(50) Cabeçalho Tabela_Preco Código da Tabela de Preço Caracter(03) Cabeçalho Tabela_Descricao Descrição da Tabela de Preço Caracter(20) Cabeçalho Cond_Pag Condição de Pagamento Caracter(03) Cabeçalho Cond_Descricao Descrição da Cond. de Pagamento Caracter(20) Cabeçalho Data_Emissao Data de Emissão do Pedido Caracter(08) Cabeçalho Data_Entrega Data de Entrega do Pedido Caracter(08) Itens/Item Produto Código do Produto Caracter(08) Itens/Item Quantidade Quantidade do Produto Numérico(4,0) Itens/Item Valor_Unitario Valor do Produto Numérico(10,2) Itens/Item Total_Item Valor total do Item Numérico(10,2) Itens/Item Perc_Desconto Percentual de Desconto Numérico(5,2) Itens/Item Preço_Desconto Valor do Produto com Desconto Numérico(10,2) Itens/Item Total_ItemDesconto Valor total do Item com Desconto Numérico(10,2) Itens/Item Tipo_Item Tipo do Item (P Pedido, B Bonificação) Caracter(01) Analises Status_Financeiro Status da Análise Financeira (S Análise OK, N Pedido bloqueado Caracter(01) para avaliação do gestor financeiro) Analises Mensagem_Financeiro Mensagem referente à Análise Financeira (Status Financeiro = N ) Caracter(1024) Analises Status_Logistica Status da Análise Logística (S Análise OK, N Pedido bloqueado para avaliação do gestor logístico) Caracter(01) Analises / Mensagem Analises Analises Analises Mensagem Status_Comercial Mensagem_Comercial Mensagem_Geral Mensagens referente à Análise Logística (Status_Logistica = N ) Status da Análise Comercial (S Análise OK, N Pedido bloqueado para avaliação do gestor Comercial) Mensagem referente à Análise Comercial (Status_Comercial = N ) Mensagem com relação a inserção do Pedido na base como pedido ou orçamento Caracter(1024) Caracter(01) Caracter(1024) Caracter(1024) 104

118 A próxima seção apresenta o Web Service WS_VALIDACAO que compõe o Web Service WS_PEDIDOS Implementação Web Service - WS_VALIDACAO O Web Service WS_VALIDACAO é um componente de muita importância para o Web Service WS_PEDIDOS que executa o processo de Negócios Pedidos, sendo que este Web Service valida as informações enviadas de uma aplicação cliente para posteriormente serem executadas pelo Workflow WFPedidos. A seguir será detalhado a implementação do Web Service. O WS_VALIDACAO possui a seguinte interface (camada de apresentação) exibida no código da Figura 57. [ServiceContract] public interface IWS_VALIDACAO { [OperationContract] string ValidacaoPedido(string strxml); } [OperationContract] string ValidacaoConsultaPedido (string strxml); Figura 57. Interface IWS_VALIDACAO A Tabela 13 exibe a descrição das funcionalidades dos métodos do serviço. Tabela 13. Métodos do Web Service WS_VALIDACAO. Métodos ValidacaoPedido ValidacaoConsultaPedido Funcionalidade dos Métodos Tem a função de executar a Validação dos dados do pedido. Este método análises os dados do cabeçalho do pedido (cliente, vendedor, tabela de preço) e itens do pedido (produtos). Tem a função de executar uma consulta de pedidos conforme a string XML informada no parâmetro. Este método é utilizado pelo Processo de Negócio Acompanhamento de Pedidos. Quando o Web Service WS_VALIDACAO é invocado por WFPedidos é executado o método ValidacaoPedido que recebe como parâmetro uma string XML contendo o pedido enviado pela aplicação cliente. Esta string é enviada para a classe WS_PEDIDOS (pacote Classes.ControleServico) e repassada para a classe ValidacaoCT (pacote Classes.Controle). 105

119 A classe ValidacaoCT recebe a string XML, instancia e executa o Workflow WFValidacao enviando como parâmetro a string XML. WFValidacao recebe a string e inicia o processo de validação. O método ValidacaoConsultaPedido é invocado pelo Web Service WS_ACMP_PEDIDOS que é utilizado para executar um consulta ou acompanhamento de pedidos. Informações gerais sobre a estrutura do XML de entrada e saída do Web Service WS_VALIDACAO, como os campos que compõe estes XML, a descrição as características destes campos estão disponíveis na seção B.1 do apêndice B A Figura 58 exibe a seqüência executada pelo Workflow WFValidacao responsável pelas regras de negócio que executam a validação do pedido. Figura 58. Workflow WFValidacao O Workflow WFValidacao que compõe o Web Service WS_VALIDACAO interage com outros Web Services representado na Figura 58 (Bloco ValidacaoPedido) pelo passo 2. A seguir são apresentados os passos deste Workflow. PASSO 1 Neste passo é executado o código do procedimento caseparadados, que neste caso tem a função de separar os dados do cabeçalho do pedido como cliente, condição de pagamento, tabela de 106

120 preço e vendedor, e os dados dos itens como produto, quantidade, valor e armazená-los para que sejam utilizados em outras etapas do Workflow. PASSO 2 No passo é onde são executadas as principais regras deste Web Service. Neste passo são invocados os seguintes Web Services: WS_CLIENTES: no procedimento cavalidacaocliente é invocado este Web Service chamando o método ValidaCliente enviando como parâmetro uma string XML para efetuar a validação do cliente, identificando se é um cliente válido ou não para o pedido em questão. O retorno do Web Service é uma string XML com as informações sobre a validação; WS_CONDPG: no procedimento cavalidacaocondpg é invocado este Web Service chamando o método ValidaCondPag enviando como parâmetro uma string XML para efetuar a validação da condição de pagamento, identificando se é uma condição de pagamento válida ou não para o pedido em questão. O retorno do Web Service é uma string XML com as informações sobre a validação; WS_TABPRECO: no procedimento cavalidacaotabpreco é invocado este Web Service chamando o método ValidaTabPreco enviando como parâmetro uma string XML para efetuar a validação da tabela de preço, identificando se é uma tabela válida ou não para o pedido em questão. O retorno do Web Service é uma string XML com as informações sobre a validação; WS_VENDEDORES: no procedimento cavalidacaovendedor é invocado este Web Service chamando o método ValidaVendedor enviando como parâmetro uma string XML para efetuar a validação do produto, identificando se é um vendedor válido ou não para o pedido em questão. O retorno do Web Service é uma string XML com as informações sobre a validação; WS_PRODUTOS: no procedimento cavalidacaoprodutos é invocado este Web Service chamando o método ValidaProduto enviando como parâmetro uma string XML para efetuar a validação da tabela de preço, identificando se é uma tabela 107

121 válida ou não para o pedido em questão. O retorno do Web Service é uma string XML com as informações sobre a validação; Os Web Services WS_CLIENTE, WS_CONDPG, WS_VENDEDORES, WS_TABPRECO E WS_PRODUTOS estão disponíveis no apêndice B que contém informações gerais sobre a estrutura dos XML de entrada e saída destes Web Services, como os campos que compõe estes XML, a descrição dos campos e as características destes campos. PASSO 3 Neste passo executa-se o procedimento cafinalizaprocesso que finaliza o Workflow WFValidacao. Assim, o procedimento cafinalizaprocesso prepara um conjunto de informações com os resultados das validações e retorna uma string XML para a classe ValidacaoCT que instanciou e iniciou este Workflow Implementação Web Service WS_ANALISE_FIN O Web Service WS_ANALISE_FIN tem uma função muito importante no processo de Negócio de Pedidos que é executar a análise financeira do pedido. Este Web Service possui duas funções, uma é analisar o Pedido enviado pela aplicação cliente e a outra é executar a aprovação de Pedidos bloqueados pela análise financeira, operação esta executada pelo gestor financeiro. O WS_ANALISE_FIN possui a seguinte interface (camada de apresentação) exibida no código da Figura 59. [ServiceContract] public interface IWS_ANALISE_FIN { [OperationContract] string AnaliseFinPedido(string strxml); } [OperationContract] string AprovacaoFinPedido(string strxml); Figura 59. Interface IWS_ANALISE_FIN A Tabela 14 exibe a descrição das funcionalidades dos métodos do serviço. 108

122 Tabela 14. Métodos do Web Service WS_ANALISE_FIN. Métodos AnaliseFinPedido AprovacaoFinPedido Funcionalidade dos Métodos Tem a função de executar a análise financeira do pedido. Este método executa a análise através da string XML recebida como parâmetro. Tem a função de executar a aprovação financeira processada pelo analista financeiro. Quando a análise é invocada pelo Workflow WFPedidos do Web Service WS_PEDIDOS o método AnaliseFinPedido recebe como parâmetro uma string XML contendo informações (CNPJ do cliente, total do pedido) para que seja executada a análise financeira. O método AprovacaoFinPedido é invocado na aprovação financeira do Pedido quando o pedido estiver bloqueado. Esta aprovação é executada pelo gestor financeiro utilizando a tela apresentada na Figura 73 do apêndice A A classe AnaliseFinCT recebe as informações da string e invoca a classe AnaliseFinDB (método AnaliseFinPedido) do pacote Classes.Banco enviando como parâmetro o CNPJ do cliente para que a consulta as informações financeiras do cliente sejam consultadas no banco de dados. As informações retornadas em uma string XML são tratadas pela classe WS_ANALISE_FIN que em seguida monta uma nova string XML com o resultado da análise que e é enviada para o Workflow WFPedidos, é dado então continuidade ao fluxo do pedido. Informações gerais sobre a estrutura dos XML de entrada e saída do Web Service WS_ANALISE_FIN, como os campos que compõe estes XML, a descrição dos campos e a características destes campos estão disponíveis na seção B.2 do apêndice B Implementação Web Service WS_ANALISE_LOG O Web Service WS_ANALISE_LOG executa no processo de Negócio de Pedidos a análise logística do pedido. Este Web Service possui duas funções, uma é analisar o Pedido enviado pela aplicação cliente e a outra é executar a aprovação de Pedidos bloqueados pela análise logística, operação esta executada pelo analista da logística. O WS_ANALISE_LOG possui a seguinte interface (camada de apresentação) exibida no código da Figura

123 [ServiceContract] public interface IWS_ANALISE_LOG { [OperationContract] string AnaliseLogPedido(string strxml); } [OperationContract] string AprovacaoLogPedido(string strxml); Figura 60. Interface IWS_ANALISE_LOG A Tabela 15. Métodos do Web Service WS_ANALISE_LOG. exibe a descrição das funcionalidades dos métodos do serviço. Tabela 15. Métodos do Web Service WS_ANALISE_LOG. Métodos AnaliseLogPedido AprovacaoLogPedido Funcionalidade dos Métodos Tem a função de executar a análise logística do pedido. Este método executa a análise através da string XML recebida como parâmetro. Tem a função de executar a aprovação logística processada pelo analista da logística. Quando a análise é invocada pelo Workflow WFPedidos do Web Service WS_PEDIDOS o método AnaliseLogPedido recebe como parâmetro uma string XML com os dados do pedido (produtos, vendedor) para que seja executada a análise logística. O método AprovacaoLogPedido é invocado na aprovação logística do Pedido quando o pedido estiver bloqueado. Esta aprovação é executada pelo gestor da logística utilizando a tela apresentada na Figura 74 do apêndice A A classe AnaliseLogCT recebe as informações da string e invoca a classe AnaliseLogDB (método AnaliseLogPedido) do pacote Classes.Banco e o Web Service WS_COTAS (método GetCotas) enviando as informações (data emissão, produtos e vendedor) do pedido para que a consulta as informações logísticas do pedido sejam executadas. As informações retornadas em uma string XML são tratadas pela classe WS_ANALISE_LOG que em seguida monta uma nova string XML com o resultado da análise e é enviada para o Workflow WFPedidos, é dado então continuidade ao fluxo do pedido. Informações gerais sobre a estrutura dos XML de entrada e saída do Web Service WS_ANALISE_LOG, como os campos que compõe estes XML, a descrição dos campos e a características destes campos estão disponíveis na seção B.3 do apêndice B 110

124 3.3.6 Implementação Web Service WS_ANALISE_CML O Web Service WS_ANALISE_CML tem a função executar a análise comercial do pedido. Este Web Service possui duas funções, uma é analisar o Pedido enviado pela aplicação cliente e a outra é executar a aprovação de Pedidos bloqueados pela análise comercial, operação esta executada pelo analista comercial. O WS_ANALISE_CML possui a seguinte interface (camada de apresentação) exibida no código da Figura 61. [ServiceContract] public interface IWS_ANALISE_CML { [OperationContract] string AnaliseCmlPedido(string strxml); } [OperationContract] string AprovacaoCmlPedido(string strxml); Figura 61. Interface IWS_ANALISE_CML A Tabela 16 exibe a descrição das funcionalidades dos métodos do serviço. Tabela 16. Métodos do Web Service WS_ANALISE_CML. Métodos AnaliseCmlPedido AprovacaoCmlPedido Funcionalidade dos Métodos Tem a função de executar a análise comercial do pedido. Este método executa a análise através da string XML recebida como parâmetro. Tem a função de executar a análise comercial processada pelo gestor comercial. Quando a análise é invocada pelo Workflow WFPedidos do Web Service WS_PEDIDOS o método AnaliseCmlPedido recebe como parâmetro a string XML contendo informações do pedido para que seja executada a análise comercial. O método AprovacaoCmlPedido é invocado na aprovação comercial do Pedido quando o pedido estiver bloqueado. Esta aprovação é executada pelo gestor comercial conforme utilizando a tela apresentada na Figura 75 do apêndice A A classe AnaliseCmlCT recebe as informações da string e invoca a classe AnaliseCmlDB (método AnaliseCmlPedido) do pacote Classes.Banco enviando as informações (produtos, vendedor) do pedido para que a consulta as informações logísticas do pedido sejam acessadas no banco de dados. As informações retornadas em uma string XML são tratadas pela classe 111

125 WS_ANALISE_CML que em seguida monta uma nova string XML com o resultado da análise e é enviada para o Workflow WFPedidos, é dado então continuidade ao fluxo do pedido. Informações gerais sobre a estrutura dos XML de entrada e saída do Web Service WS_ANALISE_CML, como os campos que compõe estes XML, a descrição dos campos e a características destes campos estão disponíveis na seção B.4 do apêndice B Implementação Web Service WS_ACMP_PEDIDOS O WS_ACMP_PEDIDOS é o Web Service responsável pelo Processo de Negócios de Acompanhamento de Pedidos. Nesta seção será demonstrado o processo utilizado no seu desenvolvimento. O WS_ACMP_PEDIDOS possui a seguinte interface (camada de apresentação) exibida no código da Figura 62. [ServiceContract] public interface IWS_ACMP_PEDIDOS { [OperationContract] string ConsultaPedidos(string strxml); } Figura 62. Interface IWS_ACMP_PEDIDOS A Tabela 17 exibe a descrição das funcionalidades dos métodos do serviço. Tabela 17. Métodos do Web Service WS_ACMP_PEDIDOS. Métodos ConsultaPedidos Funcionalidade dos Métodos Tem a função de executar uma consulta de pedidos conforme parâmetros informados através de uma string XML. O método ConsultaPedidos da classe WS_ACMP_PEDIDOS executa a consulta de pedidos quando for invocado por algum sistema ou aplicação. Como parâmetro recebe uma string XML contendo informações para a consulta. Esta informações são validadas pelo Web Service WS_VALIDACAO da mesma forma como os dados são validados no Processo de Negócio Pedidos apresentado anteriormente. No caso de a aplicação utilizada para a consulta for a Ferramenta de Pedidos On-Line da empresa, a interface gráfica é a apresentada na Figura 76 do Apêndice A. 112

126 A classe Acmp_PedidosCT recebe a string XML enviada pela classes WS_ACMP_PEDIDOS, trata os dados recebidos para em seguida requisitar a consulta ao banco de dados. Assim, a classe Acmp_PedidosCT envia as informações de consulta ao banco de dados para a classes Acmp_PedidosDB (método ConsultaPedidosDB), esta classe executa a consulta e envia para a classe Acmp_PedidosCT as linhas de retorno desta consulta. A classes Acmp_PedidosCT trata as informações e monta uma string XML e envia para a classe WS_ACMP_PEDIDOS. A classes WS_ACMP_PEDIDOS que implementa este Web Service envia para a camada de apresentação uma string XML com a consulta de pedidos que em seguida é enviada para a aplicação cliente. A seguir são apresentadas as string XML de entrada e saída deste Web Service e estrutura dos XML. Consumindo Serviço Aplicação / Sistema String XML Enviada <?xml version="1.0" encoding="utf-8"?> <xml> <Autenticacao> <Login>ADM</Login> <Senha>XYZ</Senha> </Autenticacao> <Parametros> <DataInicio> </DataInicio> <DataFim> </DataFim> <PedidoInicio>0001</PedidoInicio> <PedidoFim>0100</PedidoFim> <TipoPedido>P</TipoPedido> <Situacao>N</Situacao> <Cliente_Codigo></Cliente_Codigo> <Cliente_Loja></Cliente_Loja> <Vendedor>000079</Vendedor> </Parametros> </xml> String XML Retorno <?xml version="1.0" encoding="utf-8"?> <xml> <ListaPedidos> <Pedido> <Num_Pedido>01004</Num_Pedido> <Emissao> </Emissao> <Entrega> </Entrega> <Situacao>Importado</Situacao> <Tipo>P</Tipo> <Cliente_Codigo>010101</Cliente_Codigo> <Cliente_Nome>CLIENTE 1</Cliente_Nome> <Cliente_Loja>01</Cliente_Loja> <Vendedor_Codigo>000079</Vendedor_Codigo> <Vendedor_Nome>VENDEDOR 1</Vendedor_Nome> </Pedido> </ListaPedidos> </xml> WEB SERVICE WS_ACMP_PEDIDOS (Método ConsultaPedidos) Figura 63. XML WS_ACMP_PEDIDOS A Figura 63 exibe como funciona de forma geral o Web Service WS_ACMP_PEDIDOS. Uma string XML é enviada por uma aplicação cliente e é processada pelo Web Service, que envia uma string XML de retorno para a aplicação cliente. 113

127 A Tabela 18 a seguir detalha a estrutura do XML de entrada recebido pela aplicação cliente informando os campos, os grupos a que estes campos pertencem dentro da string XML e as características do campo (tipo e tamanho). Tabela 18. Estrutura XML de entrada WS_ACMP_PEDIDOS. Grupo Campo Descrição Tipo Autenticacao Login Nome do usuário Caracter(10) Autenticacao Senha Senha criptografada Caracter(1024) Parametros DataInicio Data de Início para a Consulta Caracter(08) Parametros DataFim Data de Fim para a Consulta Caracter(08) Parametros PedidoInicio Pedido Inicial para a Consulta Caracter(15) Parametros PedidoFim Pedido Final para a Consulta Caracter(15) Parametros TipoPedido Tipo do Tipo (P Pedido B Bonificação) Caracter(01) Parametros Situacao Situação do Pedido (I Importado N - Não Importado) Caracter(01) Parametros Cliente_Codigo Código do Cliente do Pedido Caracter(06) Parametros Cliente_Loja Loja do Cliente do Pedido Caracter(02) Parametros Vendedor Código do Vendedor do Pedido Caracter(06) A seguir é apresentada a Tabela 19 com o detalhamento das informações geradas pelo Web Service WS_ACMP_PEDIDOS (método ConsultaPedidos) e que são enviadas para a aplicação cliente. Tabela 19. Estrutura XML de saída WS_ACMP_PEDIDOS (método ConsultaPedidos). Grupo Campo Descrição Tipo ListaPedidos / Pedido Num_Pedido Número do Pedido Caracter (15) ListaPedidos / Pedido Emissao Data de Emissão do Pedido Caracter (08) ListaPedidos / Pedido Entrega Data de Entrega do Pedido Caracter (08) ListaPedidos / Pedido Situacao Situação do Pedido (Importado ou Não Importado) Caracter (15) ListaPedidos / Pedido Tipo Tipo do Pedido (Pedido ou Bonificação) Caracter (15) ListaPedidos / Pedido Cliente_Codigo Código do Cliente do Pedido Caracter (06) ListaPedidos / Pedido Cliente_Nome Nome do Cliente do Pedido Caracter (100) ListaPedidos / Pedido Cliente_Loja Loja do Cliente do Pedido Caracter (02) ListaPedidos / Pedido Vendedor_Codigo Código do Vendedor do Pedido Caracter (06) ListaPedidos / Pedido Vendedor_Nome Nome do Vendedor do Pedido Caracter (30) 114

128 3.3.8 Implementação Repositório de Serviços Os repositórios de serviços são uma peça fundamental no contexto da Arquitetura Orientada a Serviço, mas, como os Web Services também não é um tema novo. Como apresentado na seção , o repositório de serviço visa fornecer um diretório para busca de negócios e seus serviços (Web Services), tanto para a empresa como para seus parceiros de negócios. Sua principal função é ser um mediador do serviço, possibilitando que aplicações clientes encontrem as informações necessárias de um serviço, como localização física do serviço, sua interface e detalhes técnicos e de negócios. Assim, este projeto apresenta a implementação de um repositório de serviços através das especificações da UDDI apresentada na seção , mais especificamente a implementação dos Serviços UDDI disponível no sistema operacional Microsoft Windows Server 2003 Enterprise Edition, tecnologia utilizada neste projeto. A implementação da UDDI neste projeto ocorreu da seguinte forma: 1. Instalação dos Serviços UDDI no servidor Windows 2003 Server; 2. Configuração dos Serviços UDDI no servidor Windows conforme Figura 64; Figura 64. Configuração - Servidor UDDI 3. Configuração do Site UDDI no IIS (Internet Information Services Gerenciador de Informações da Internet) do servidor Windows 2003 apresentada na Figura 65; 115

129 Figura 65. Configuração - Site UDDI 4. Configuração de um provedor de Serviços da empresa no Site UDDI exibido na Figura 66; e Provedor de Serviços Figura 66. Configuração Provedor de Serviços 5. Publicação dos Serviços no Site UDDI conforme Figura

130 Figura 67. Serviços Publicados Depois de efetuadas as configurações anteriores, os serviços já estão disponíveis para serem descobertos e identificados no repositório de serviços por aplicações da própria empresa ou aplicações de terceiros. Para utilizar o repositório, a aplicação cliente deverá saber as seguintes informações: o endereço do repositório, a chave do Provedor e o nome do serviço. Porém, cada aplicação cliente localiza os serviços no repositório baseado nas suas características (linguagem, plataforma), mas, sempre utilizando os padrões UDDI. Estes padrões, segundo Reis e Célio (2007), baseiam-se na estrutura do registro UDDI que define uma hierarquia através dos elementos: businessentity: representa o provedor de um Web Service. Apresenta dados de contato, categoria, serviços oferecidos, identificadores de negócio de uma determinada organização / empresa. businessservice: elemento filho do elemento businessentity, descreve a função de negócio de um serviço. Indicadores únicos que indicam as categorias as quais os Web Services pertencem (businesskey, servicekey); 117

131 bindingtemplate: referencia os detalhes técnicos do serviço, interface ou API; e tmodels: qualquer conceito abstrato pode ser registrado, como taxonomia, transportes, assinaturas digitais, etc. Em muitos casos, o tmodel contém o arquivo WSDL que descreve a interface SOAP do serviço. Figura 68. Estrutura UDDI A Figura 68 exibe a estrutura UDDI descrita anteriormente. É importante relembrar que, cada aplicação cliente utiliza esta estrutura conforme suas características. Cada provedor (businessentity) possui um businesskey e cada serviço (businessservice) possui um servicekey que são respectivamente as chaves de acesso ao provedor e ao serviço e podem ser utilizados pela aplicação cliente para localizar e consumir os serviços do repositório Testes e Validações dos Processos de Negócios, Serviços e Repositório de Serviços Os testes e as validações dos Processos de Negócios, Serviços e Repositório de Serviços propostos e implementados neste projeto, têm como objetivo evidenciar que estes estão funcionando corretamente e que podem ser implantados no protótipo da SOA na empresa, sendo este outro objetivo do projeto. Assim, para poder testar e validar os Processos de Negócios, Serviços e Repositório foi desenvolvido uma aplicação Web simples, com a finalidade de ser uma aplicação cliente que consome os serviços que executam os Processos de Negócio Pedidos (representado pelo Web Service WS_PEDIDOS) e Acompanhamento de Pedidos (representado pelo Web Service WS_ACMP_PEDIDOS) e também os demais Web Services que compõe estes Processos de Negócio. 118

132 Além de testar e validar os Web Services a aplicação também permite testar o funcionamento do Repositório de Serviços, permitindo descobrir os Web Services publicados no repositório. A aplicação Web faz parte do pacote ValidacaoWEB apresentado na seção Estrutura do Projeto e através desta aplicação foram executados os testes dos Web Services que permitiram validar as informações processadas e enviadas para a aplicação cliente. No Apêndice B e nas seções (WS_PEDIDOS) e (WS_ACMP_PEDIDOS) estão disponíveis figuras que demonstram a execução dos métodos dos Web Services a partir de um XML de Entrada que é processado e gera um XML de Saída. Para testar e validar os Processos de Negócios e Web Service foi implementada a página Web exibida na Figura 69. Figura 69. Testes / Validação Web Services 119

133 A Figura 69 exibe a interface gráfica utilizada para os Testes e a Validação dos Web Services e que para ser executado possui os seguintes passos: 1. Preencher o campo com um XML de Entrada; 2. Escolher o Web Service / Método a ser executado; 3. Clicar no Botão Executar; e 4. É exibido o XML de Saída, resultado do processamento do Web Service. Para testar e validar o Repositório de Serviços foi implementada a página Web exibida na Figura 70. Figura 70. Testes / Validação Repositório de Serviços 120

134 A Figura 70 exibe a interface gráfica utilizada para os Testes e a Validação do Repositório de Serviços e que para ser executado possui os seguintes passos: 1. Preencher o campo com o nome do Web Service que se deseja descobrir; 2. Clicar no Botão Descobrir Serviço, sendo que este botão executa o processo de descoberta do Web Service; e 3. Na caixa da Figura 70 são exibidas as informadas do processo de descoberta do Web Service. Desta forma foram testados e validados os Processos de Negócio, Serviços e o Repositório de Serviços. O teste e a validação no XML de Saída permitiu verificar que os dados processados pelos Web Services estão corretos. Já as informações obtidas na descoberta dos Web Services permitiram evidenciar o correto funcionamento do Repositório de Serviços que possibilita que os serviços publicados sejam descobertos e identificados. Portanto, os Processos de Negócio, Serviços e o Repositório de Serviços estão testados, validados e disponíveis para serem utilizados na Implantação do Protótipo da SOA na empresa Implantação e Validação do Protótipo da SOA O processo de Implantação e Validação do Protótipo da SOA na empresa ocorreu com a integração dos Web Services implementados com a Ferramenta de Pedidos On-Line. Assim sendo, para o processo Implantação e Validação do Protótipo da SOA ocorreram os seguintes passos: PASSO 1: Integração Web Services com a Ferramenta de Pedidos On-Line Esta integração ocorreu substituindo o código (procedimentos e funções) escrito na Aplicação atual desenvolvida em Delphi No lugar deste código foi implementado no Delphi 2005 o código que consumiu os Web Services e tratou as informações que os Web Service retornam 121

135 para a Aplicação de Pedidos On-Line que continuará com as interfaces gráficas desenvolvidas em Delphi. A Figura 71 do apêndice A exibe a interface gráfica da Inclusão de Pedidos, evidenciando os pontos onde são consumidos alguns dos Web Services implementados neste projeto. PASSO 2: Implantação Após a integração dos Web Services no passo 1, foi dado continuidade na implantação publicando as alterações efetuadas na Ferramenta de Pedidos On-Line. Neste momento a Implantação do Protótipo da SOA foi concluída e a Ferramenta disponibilizada para validação. PASSO 3: Validação A validação da Implantação Protótipo da SOA na empresa foi executada pelo Gerente Operacional responsável pelos Negócios relacionados à Ferramenta de Pedidos On-Line nas duas versões, Cenário Atual e Cenário Proposto. Entende-se por Cenário Atual (seção 3.1) a implementação Ferramenta através de procedimentos e funções e por Cenário Proposto (seção 3.2) a implementação da Ferramenta por meio de Web Services. Assim, para efetuar a validação os seguintes procedimentos foram executados: 1. Foram disponibilizadas ao Gestor as duas versões (Cenário Atual e Proposto) para executar os procedimentos da utilização da Ferramenta de Pedidos On- Line de forma completa: Inclusão / Alteração / Exclusão de Pedidos, Aprovações (Financeira, Comercial e Logística) e Acompanhamento de Pedidos; 2. Foi verificada a aceitação do Gestor em relação à utilização da Ferramenta de Pedido On-Line na versão Cenário Proposto (Protótipo SOA). Foram efetuadas ao Gestor perguntas relacionadas à utilização e aceitação da Ferramenta e obtidas às seguintes respostas: a. Os procedimentos de Inclusão / Alteração / Exclusão de Pedidos funcionaram corretamente? Caso a resposta seja não, citar o(s) problema(s) constatado(s). 122

136 Resposta: Sim funcionaram corretamente. Inclusive as mensagens no histórico do Pedido foram aprimoradas. b. O procedimento de Aprovação Financeira funcionou corretamente? Caso a resposta seja não, citar o(s) problema(s) constatado(s). Resposta: Sim funcionou corretamente. Houve ainda melhora no envio de sobre a aprovação, sendo que o mesmo não informava o motivo. c. O procedimento de Aprovação Logística funcionou corretamente? Caso a resposta seja não, citar o(s) problema(s) constatado(s). Resposta: Sim funcionou corretamente. Houve melhora nas informações, foi adicionada a informação de aprovação parcial. d. O procedimento de Aprovação Comercial funcionou corretamente? Caso a resposta seja não, citar o(s) problema(s) constatado(s). Resposta: Sim funcionou corretamente. e. O procedimento de Acompanhamento de Pedidos (Consulta de Pedidos) funcionou corretamente? Caso a resposta seja não, citar o(s) problema(s) constatado(s). Resposta: Sim funcionou corretamente. Houve ainda ajustes na ordem que as mensagens no histórico são exibidas. Com a execução destes 3 (três) passos foi possível Implantar e Validar o Protótipo da SOA na empresa. Ainda durante a validação foi possível verificar na prática as vantagens da utilização da SOA, sendo que ela possibilita evoluções e melhorias de forma rápida e eficiente tanto para desenvolvimento aplicações como para o desenvolvimento de processos de negócio. 123

137 4 CONCLUSÃO Cada vez mais é necessária a comunicação entre áreas de TI e de negócios, para que em conjunto estas áreas possam agregar mais valor aos recursos tecnológicos e aos negócios das organizações. Neste contexto, destaca-se a necessidade da área de negócios em aprimorar e evoluir seus processos, de forma dinâmica e eficiente. É neste ponto que a área de TI entra, oferecendo recursos tecnológicos que possibilite que os negócios das organizações sejam dinâmicos e eficientes, gerando assim mais oportunidades de negócios. Sob esta ótica pode-se concluir que as organizações deveriam aprender a usufruir ao máximo os recursos disponíveis, como sistemas, bancos de dados, softwares de desenvolvimento e infra-estrutura. É neste contexto que a SOA (Service Oriented Architecture - Arquitetura Orientada a Serviços) propõe uma nova metodologia no desenvolvimento de aplicações. A SOA surge como uma solução para vencer as dificuldades relativas ao desenvolvimento e integração de sistemas em ambientes heterogêneos e que possivelmente possam sofrer mudanças. Desta forma, este projeto procurar auxiliar a empresa a melhorar os Processos de Negócio destacados na seção 3.1, e tem como objetivo geral otimizar os processos de negócio na ferramenta de Pedidos On-Line, possibilitando que novas mudanças nos processos e regras de negócios sejam implantadas de forma eficiente e rápida. Para atingir o objetivo geral os seguintes objetivos específicos foram alcançados: Projetos Similares (seção 2.3): este projeto foi inspirado além da literatura encontrada, por projetos similares pesquisados, que apresentam a utilização dos principais conceitos relacionados à Arquitetura Orientada a Serviço e que foram apresentados como monografia e dissertação em cursos de Pós-Graduação e serviram como referência para o início dos estudos deste projeto. Conceitos, características e tecnologias da SOA (seção 2.1): para desenvolver o Protótipo da SOA proposto neste projeto, fez-se necessário pesquisar conceitos, características e tecnologias da Arquitetura Orientada a Serviço. Os conceitos estudados possibilitaram obter embasamento científico sobre a SOA e quais os reflexos quando utilizados. As características permitiram definir qual seria a melhor forma para a implementação da Arquitetura na empresa, fornecendo conhecimento para a escolha da metodologia para esta implementação. Já o estudo sobre as tecnologias utilizadas na SOA, possibilitou conhecer e escolher as tecnologias de forma adequada,

138 permitiu ainda, saber em qual momento da implementação cada uma seria utilizada. Assim, ficou definido Web Services como a tecnologia base para a implementação da SOA. BPM e implementação de Web Services (seção 2.2): como o próprio título deste projeto cita: Utilização da Arquitetura Orientada a Serviço (SOA) como Ferramenta para Otimização de Processos de Negócios, foi necessário entrar em uma camada mais abstrata que são os negócios. Para tal foram pesquisados os conceitos, características, tecnologias e padrões relacionados à BPM (Gestão de Processos de Negócios), BPEL (Linguagem de Execução de Processos de Negócio) e implementação de Web Services, visando obter conhecimento da Gestão de Processos de Negócios. O estudo realizado possibilitou conhecer melhor a BPM, quais as influências e benefícios da BPM para este projeto e como utilizá-los. O estudo sobre BPEL permitiu verificar de que forma a BPM poderia ser implementada na SOA e que tecnologias dentre as disponíveis na empresa seria a melhor para o desenvolvimento dos processos de negócio. Com base nos estudos realizados sobre BPM e BPEL pôde-se definir o padrão de implementação dos Web Services em relação aos Processos de Negócios. Modelagem dos Processos de Negócio e Serviços (seções e ): após todos os estudos realizados sobre conceitos, características, padrões e tecnologias que fazem parte do universo da SOA foram modelados os Processos de Negócio e Serviços. Assim, a modelagem dos Processos de Negócio centralizaram-se em dois processos, o Processo de Negócio Pedidos, responsável pela inclusão, alteração e exclusão de pedidos de venda, representado na implementação pelo Web Service WS_PEDIDOS e o Processo de Negócios Acompanhamento de Pedidos, representado na implementação pelo Web Service WS_ACMP_PEDIDOS. Estes Processos de Negócios são fundamentais para a área comercial da empresa, sendo que atendem toda a equipe de vendas da empresa. A modelagem proposta visou solucionar os problemas apresentados na seção tornando os processos de negócios mais dinâmicos, possibilitando maior agilidade nas mudanças das Regras de Negócios. A modelagem dos Serviços procurou tornar os procedimentos executados pelos Processos de Negócios mais independentes, reutilizáveis, permitindo aos Serviços aprimorar sua implementação e suas Regras de Negócio com base nas características da SOA como fraco acoplamento, autonomia e reusabilidade. Ferramentas / Tecnologias para Implementação (seção ): através dos estudos realizados sobre a SOA e dentre as tecnologias disponíveis pela empresa foi definido que a melhor ferramenta para a implementação deste projeto é o Microsoft Visual Studio 2008 e as tecnologias 125

139 WCF (Windows Communication Foundation) para Implementação de Serviços, WWF (Windows Workflow Foundation) para implementação dos Processos de Negócio (orquestração) e o IIS (Internet Information Services) que é um servidor Web disponível no Sistema Operacional Microsoft Windows Server 2003 Enterprise Edition utilizado neste projeto para implementação e publicação do Repositório de Serviços. Implementação de Web Services (seções à e apêndice B ): após o desenvolvimento da modelagem foi possível implementar os Web Services necessários para o desenvolvimento da SOA. Os Web Services foram implementados na Ferramenta Microsoft Visual Studio 2008 através da tecnologia WCF. Estes Web Services compõem os Processos de Negócios e também podem ser reutilizados por outras aplicações. A metodologia utilizada para o desenvolvimento dos Web Services foi a de camadas (apresentação, negócio e dados) que possibilita um fraco acoplamento também no nível de código o que facilita a reusabilidade das classes e métodos implementados. Implementação dos Processos de Negócio (seções e ): com a modelagem dos Processos de Negócios e Serviços definidos e com a implementação dos Web Services foi possível implementar os Processos de Negócio Pedidos e Acompanhamento de Pedidos, implementados como Web Services centralizadores, consumindo e coordenando os demais Web Services, caracterizando assim um cenário de orquestração. O Processo de Negócio Pedidos foi implementado através do Web Service WS_PEDIDOS e o Processo de Negócio Acompanhamento de Pedidos foi implementados através do Web Services WS_ACMP_PEDIDOS. Testes e Validações (seção ): ao concluir a implementação dos Processos de Negócio e Serviços foi implementada uma aplicação Web para permitir testar e validar a execução dos Processos de Negócio e Serviços. Assim, após a execução da aplicação pôde-se concluir que os Processos de Negócio e os Serviços funcionam corretamente e podem ser implantados na SOA da empresa. Implantação do Protótipo SOA (seção ): concluídas as implementações, os testes e validações dos Processos de Negócio e Serviços, foi Implantado e Validado o Protótipo da SOA na empresa juntamente com o Gerente Operacional, responsável pelos negócios relacionados a Ferramenta de Pedidos On-Line, que evidenciou o correto funcionamento do Protótipo. 126

140 Este projeto é importante para o meio acadêmico, para o autor do projeto e para a empresa, pois oferece literatura sobre um tema (Arquitetura Orientada a Serviço) em evidência no mercado e uma aplicação prática. Para o meio acadêmico a importância está relacionada à forma como o projeto foi idealizado, modelado e implementado, utilizando para isto conhecimentos adquiridos ao longo da formação acadêmica e na atuação profissional, como o levantamento de requisitos, modelagem, desenvolvimento de aplicações e a visão de negócios. Os estudos realizados neste projeto também disponibilizam uma literatura diversificada sobre a Arquitetura Orientada a Serviço e como a teoria apresentada pode ser aplicada na prática com a implementação de um protótipo da SOA, sendo que esta literatura fica a disposição de alunos, professores e da comunidade em geral servindo como base para pesquisas e trabalhos futuros. Para o autor deste projeto, a importância ultrapassa os limites acadêmicos e atinge fortemente a vida profissional, sendo que o desenvolvimento do projeto proporcionou conhecimentos técnicos e de negócios que serão aproveitados por toda a vida. No aspecto técnico os estudos realizados sobre as tecnologias antes desconhecidas permitiram o desenvolvimento da SOA e um melhor entendimento sobre a razão da sua existência. Já no aspecto de negócios, oportunizou conhecer melhor a empresa na qual é colaborador e os processos de negócio que este projeto utilizou como base. E para a empresa a importância deste projeto atinge diretamente os seus negócios, na medida em que podem evoluir e se transformar conforme as mudanças do mercado, agora com melhor suporte da equipe de TI, que adquiriu condições para acompanhar as evoluções e transformações ocorridas nos negócios da empresa, por meio da SOA. Assim, com base nos objetivos alcançados, verificou-se que a SOA possibilita à empresa a evolução em seus sistemas e soluções de software de forma facilitada e simplificada. Desta forma, recomendam-se como trabalhos futuros para este projeto, migrar na íntegra os portais da empresa, Portal de Pedidos, Portal BI (Ferramenta de Informações Gerenciais) e Portal KPI (Ferramenta de Informações de Desempenho) para a Arquitetura Orientada a Serviço, tornando as aplicações Web da empresa otimizadas e dinâmicas no aspecto de implementação e negócios. Como trabalhos futuros no ponto de vista da ciência abordando o tema Arquitetura Orientada a Serviços pode-se citar a implementação de uma solução ETL (Extract Transform Load 127

141 - Extração, Transformação e Carga), que possibilite capturar, trocar e receber informações de bases de dados de diferentes plataformas e aplicações para a construção de um Data Warehouse através da SOA utilizando fundamentalmente troca de mensagens e a tecnologia XML. Por fim, espera-se que este projeto possa contribuir para futuros projetos de pesquisa, para a ciência como literatura e para que a empresa possa evoluir ainda mais na implementação e consolidação da Arquitetura Orientada a Serviços aproximando cada vez mais as áreas de TI e de negócios, fornecendo melhores soluções de software que atendam as freqüentes mudanças dos processos de negócio, decorrentes da alta competitividade do mercado. 128

142 REFERÊNCIAS BIBLIOGRÁFICAS ALVES, Alexandre. Segurança nos XML Web Services. Revista MSDN Magazine edição 07. p set BENEDETE JUNIOR, Antonio Carlos. Roteiro para a definição de uma arquitetura SOA utilizando BPM. São Paulo, p. CARTER, Sandy. The new language of business: SOA e Web 2.0. United States: IBM Press, CHATTERJEE, Sandeep; WEBBER, James. Developing Enterprise Web Services: An Architect's Guide. Prentice Hall PTR, ISBN: CUNHA, Davi. Web Services, SOAP e Aplicações Web Disponível em: < Acesso em: 29 set DAUM, Berthold; MERTEN, Udo. Arquitetura de sistemas com XML. Editora Campus, DOMÍNIO. BPEL Disponível em: < Acesso em: 14 out DUTRA JUNIOR, Antonio. Fundamentos da Gestão de Processos Disponível em: < Acesso em: 06 set ERL, Thomas. Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall PTR, ISBN: ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR, ISBN: HASAN, Jefrey; DURAN, Mauricio. Expert Service-Oriented Architecture in C# ed. Apress ISBN: X. HUNTER, David et al. Beginning XML. 4 ed. Wiley Publishing Inc, ISBN: KRAFZIG, Dirk; BANKE, Karl; SLAMA, Dirk. Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall PTR, ISBN: JURIC, Matjaz B. Business Process Execution: An architect and developer s guide to orchestration web services using BPEL4WS. 2 ed. Packt Publishing, ISBN: MICROSOFT: Visão geral sobre Serviços UDDI. 2007a. Disponível em: < Acesso em: 07 out

143 MICROSOFT: Desenvolvimento em Camadas. 2007b. Disponível em: Acesso em: 20 abr NEWCOMER, Eric; LOMOW, Greg. Understanding SOA with Web Services. Addison Wesley Professional, ISBN: PELTZ, Chris. Web Service Orchestration and Coreography: A look at WSCI and BPEL4WS Disponível em < Acesso em: 05 ago REIS, Julio César; CÉLIO, Marcos Vinícius de Paiva. SOA UDDI Disponível em: < Acesso em: 28 abr SAMPAIO, Cleuton. SOA e Web Services em Java. Rio de Janeiro: Brasport, SKONNARD, Aaron. Aprenda o ABC da programação com o Índigo Disponível em: Acesso em 10 out SOUZA, Victor Alexandre Siqueira Marques de. Uma arquitetura orientada a serviços para desenvolvimento, gerenciamento e instalação de serviços de rede. Campinas, SP: [s.n.], TOFFLER, Alvin. The Third Wave edition. London: Pan Books, W3C: Web Services Architecture Disponível em < Acesso em: 07 out WEERAWARANA, Sanjiva et al. Web Services Platform Architecture: SOAP, WSDL, WS- Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More. Prentice Hall PTR, ISBN: WESKE, Mathias. Business Process Management: Concepts, Languages, Architectures. Springer, ISBN:

144 APÊNDICES

145 A TELAS DA FERRAMENTA DE PEDIDOS ON-LINE Para auxiliar na compreensão dos Processos de Negócio - Pedidos e Acompanhamento de Pedidos, são apresentadas a seguir as telas destes Processos de Negócio. É importante lembrar que todas as telas utilizados no Cenário Atual são aproveitadas para o Novo Cenário. A.1 TELAS PROCESSO DE NEGÓCIO PEDIDOS Esta seção exibe as telas do Processo de Negócio Pedidos. Estas telas são utilizadas na Ferramenta de Pedidos On-Line conforme descrição dos processos na 3.1 Cenário atual, e são mantidas na implementação da Arquitetura Orientada a Serviço. Figura 71. Interface de Inclusão do Pedido de Venda A Figura 71 exibe a interface para digitação do pedido de venda que é fornecida ao usuário caso Aplicação requerente não possua interface.

146 Figura 72. Interface de Inclusão do Pedido de Venda Consulta (Clientes, Condições de Pagamento, Produtos) A Figura 72 exibe a interface para digitação do pedido de venda com as consultas que são utilizadas para preencher os dados necessários para conclusão do Pedido. Com a implementação da SOA na Ferramenta de Pedidos On-Line, as consultas geradas de Clientes, Condições de Pagamento e Produtos são Web Services, e estes poderão ser consumidos por outros serviços ou aplicações. A Figura 72 destaca ainda o botão que executa o Web Service WS_PEDIDOS., utilizado para gravar o pedido de venda 133

147 Aprovação Financeira Painel - Análise Financeira Risco (Cisp): A Rating (Equifax): A Títulos a Vencer: 9.200,00 Títulos Vencidos: 0,00 Pedidos Pendente: 0,00 Limite Crédito: ,00 Figura 73. Interface de Aprovação Financeira A Figura 73 exibe a interface utilizada pelo Analista Financeiro para aprovar ou não um pedido de venda. Esta interface possibilita ao Analista Financeiro analisar o pedido através de informações referentes ao seu histórico de venda e sua posição atual através do painel Análise Financeira. 134

148 Figura 74. Interface de Aprovação Logística A Figura 74 exibe a interface utilizada pelo Analista Logístico para aprovar ou não um pedido de venda. A interface permite ao Analista Logístico analisar as informações relevantes para a aprovação ou não da logística do pedido, como por exemplo se há cota e/ou estoque para atender determinado item do pedido. A caixa destacada exibe a cota que é consultada pelos Web Service WS_COTA. 135

149 Aprovação Comercial Figura 75. Interface de Aprovação Comercial A Figura 75 exibe a interface utilizada pelo Gestor Comercial para Aprovação Comercial. A interface permite ao Gestor Comercial analisar as bonificações, descontos e preços praticados, para decidir sobre a aprovação ou não do pedido. 136

150 A.2 TELAS PROCESSO DE NEGÓCIO - ACOMPANHAMENTO DE PEDIDOS Esta seção exibe as telas do Processo de Negócio Acompanhamento de Pedidos. Estas telas são utilizadas na Ferramenta de Pedidos On-Line conforme descrição dos processos na 3.1 Cenário atual. Figura 76. Interface de Parâmetros: Processo de Negócio - Acompanhamento de Pedidos A Figura 76 exibe a interface para preenchimento dos parâmetros que são utilizados na consulta que gera tela de Acompanhamento de Pedidos. A Figura 76 destaca ainda o botão, utilizado para gerar a tela de Acompanhamento de Pedidos. 137