Baixe o app para aproveitar ainda mais
Prévia do material em texto
Arquitetura Orientada a Serviço Créditos Centro Universitário Senac São Paulo – Educação Superior a Distância Diretor Regional Luiz Francisco de Assis Salgado Superintendente Universitário e de Desenvolvimento Luiz Carlos Dourado Reitor Sidney Zaganin Latorre Diretor de Graduação Eduardo Mazzaferro Ehlers Diretor de Pós-Graduação e Extensão Daniel Garcia Correa Gerentes de Desenvolvimento Claudio Luiz de Souza Silva Luciana Bon Duarte Roland Anton Zottele Sandra Regina Mattos Abreu de Freitas Coordenadora de Desenvolvimento Tecnologias Aplicadas à Educação Regina Helena Ribeiro Coordenador de Operação Educação a Distância Alcir Vilela Junior Professores Autores Mikiko Ishida Éder Frances Oliveira Vinicius Moll Revisor Técnico Marcelo José Szewczyk Técnico de Desenvolvimento Ozeas Vieira Coordenadoras Pedagógicas Ariádiny Carolina Brasileiro Silva Izabella Saadi Cerutti Leal Reis Nivia Pereira Maseri de Moraes Otacília da Paz Pereira Equipe de Design Educacional Alexsandra Cristiane Santos da Silva Ana Claudia Neif Sanches Yasuraoka Angélica Lúcia Kanô Anny Frida Silva Paula Cristina Yurie Takahashi Diogo Maxwell Santos Felizardo Flaviana Neri Francisco Shoiti Tanaka Gizele Laranjeira de Oliveira Sepulvida Hágara Rosa da Cunha Araújo Janandrea Nelci do Espirito Santo Jackeline Duarte Kodaira João Francisco Correia de Souza Juliana Quitério Lopez Salvaia Jussara Cristina Cubbo Kamila Harumi Sakurai Simões Katya Martinez Almeida Lilian Brito Santos Luciana Marcheze Miguel Mariana Valeria Gulin Melcon Mônica Maria Penalber de Menezes Mônica Rodrigues dos Santos Nathália Barros de Souza Santos Rivia Lima Garcia Sueli Brianezi Carvalho Thiago Martins Navarro Wallace Roberto Bernardo Equipe de Qualidade Ana Paula Pigossi Papalia Josivaldo Petronilo da Silva Katia Aparecida Nascimento Passos Coordenador Multimídia e Audiovisual Ricardo Regis Untem Equipe de Design Audiovisual Adriana Mitsue Matsuda Caio Souza Santos Camila Lazaresko Madrid Carlos Eduardo Toshiaki Kokubo Christian Ratajczyk Puig Danilo Dos Santos Netto Hugo Naoto Takizawa Ferreira Inácio de Assis Bento Nehme Karina de Morais Vaz Bonna Marcela Burgarelli Corrente Marcio Rodrigo dos Reis Renan Ferreira Alves Renata Mendes Ribeiro Thalita de Cassia Mendasoli Gavetti Thamires Lopes de Castro Vandré Luiz dos Santos Victor Giriotas Marçon William Mordoch Equipe de Design Multimídia Alexandre Lemes da Silva Cristiane Marinho de Souza Emília Correa Abreu Fernando Eduardo Castro da Silva Mayra Aoki Aniya Michel Iuiti Navarro Moreno Renan Carlos Nunes De Souza Rodrigo Benites Gonçalves da Silva Wagner Ferri Arquitetura Orientada a Serviço Aula 01 Introdução à SOA e apresentação dos principais conceitos Objetivos Específicos • Apresentar o problema atual das empresas no que tange à integração entre sistemas (troca de arquivo, base de dados compartilhada, entre outros). Introdução 1 Introdução à SOA 2 Histórico 3 Fato: existência de silos e o impacto no negócio 4 Integração de sistemas Considerações finais Referências Temas Mikiko Ishida Professor Autor Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 2 Introdução Nesta aula, vamos introduzir os principais conceitos da Arquitetura Orientada a Serviço, do termo em inglês Service-Oriented Architecture (SOA), e conhecer alguns fatos que motivaram o seu surgimento. Para ajudar a entender os motivadores da evolução das tecnologias de integração de sistemas, uma breve passagem histórica é apresentada para explicar como o desenvolvimento do mercado e os seus respectivos impactos impulsionaram as mudanças nas empresas, apoiando-se mais e mais na Tecnologia da Informação. 1 Introdução à SOA Antes de falarmos sobre SOA, vamos fazer uma analogia com uma cidade. Cada empresa que aparece na Figura 1, “Uma cidade com empresas e serviços”, é orientada a um tipo de serviço (especialização) que pode ser utilizado por vários consumidores. Por exemplo, lavanderias, postos de combustível, restaurantes, cabeleireiros, correios, escolas, hotéis, escritórios de contabilidade, imobiliárias etc. Vamos pegar três empresas que precisam dos serviços terceirizados de uma lavanderia porque seus negócios têm outros objetivos, como um restaurante, um cabeleireiro e um hotel. Esta necessidade de negócio (lavar roupas) demanda uma integração entre cada uma dessas empresas com a lavanderia. A integração é viabilizada pelas ruas que interligam os estabelecimentos e pelos veículos que carregam as roupas (dados). O serviço de lavagem de roupas é reusável, pois esses clientes podem voltar a utilizá-lo, assim como outros estabelecimentos podem reusar o mesmo serviço. Coletivamente, essas empresas formam uma comunidade de negócios, na qual é esperado que o consumidor não seja servido por uma única empresa que ofereça todos os tipos de serviços. Figura 1 – Uma cidade com empresas de serviços Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 3 Existem quatro aspectos fundamentais na arquitetura orientada a serviço que agregam valor ao negócio. 1.1 Serviço É importante entender que estamos falando sob a ótica de processo de negócio, portanto, não pense no contexto de software ou de TI – Tecnologia da Informação. Pense sobre o que uma empresa faz no seu dia a dia e “quebre” os processos de negócio em tarefas de negócio repetíveis ou componentes. Um serviço é autodescritivo e localizável, atende a requisitos de qualidade de serviço e pode ser gerenciado pela governança. Por exemplo, serviço de verificação de crédito ou serviço de criação de uma conta nova. Podemos fazer uma analogia com aquele brinquedo de peças ou de blocos montáveis, que permite criar e montar blocos maiores ou até uma estrutura completa. Figura 2 – Peças e blocos de montagem 1.2 Orientação a serviço Assim como serviço foi definido e comparado a blocos montáveis, orientação a serviço é uma abordagem para integrar uma empresa como serviços interconectados. Ela permite aos aplicativos chamar o comportamento de outros aplicativos como serviço, com o objetivo de gerar resultados ao negócio. 1.3 A arquitetura orientada a serviço É um estilo de arquitetura de TI que usa os princípios da orientação a serviço1 para estreitar a relação entre a empresa e os sistemas de informação que suportam o seu negócio. 1 Orientação a serviço é uma abordagem para integrar uma empresa como serviços interconectados, em que uma aplicação pode chamar uma função de outra aplicação como serviço. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 4 Seu maior objetivo é alcançar a possibilidade de conectar uma ampla variedade de sistemas sem a necessidade de descartar sistemas existentes. 1.4 Aplicação composta Aplicações compostas são os serviços em execução de fato que foram montados ou construídos e “amarrados juntos”, ou seja, integrados para apoiar o que a empresa faz. A SOA ajuda a tornar a criação de aplicativos e os ajustes de aplicações compostas mais rápidos e mais fáceis. Porém, para que este modelo funcione de forma a trazer resultados ao negócio, deve-se evitar o alto nível de interdependência entre os serviços individuais, utilizando as boas práticas que a orientação a serviço nos traz. O serviço deve ter uma atividade bem definida e baixo nível de acoplamento na interação com outro serviço. Desta forma, os serviços individuais podem se autogovernar e crescer em volume, de forma relativamente independente um do outro. As arquiteturas antigas, antes do SOA, não suportam a flexibilidade e a agilidade que a demanda de negócio atualmente precisa. Geralmente as aplicações eram desenvolvidas de formas monolíticas, com todas as unidades lógicas de serviço em um único bloco. 2 Histórico A economia mundial e a tecnologia vêm se transformando de uma forma cada vez mais rápida, ajudando no desenvolvimento de ambas.Porém, esse fenômeno também causa pressão nas empresas para que se adaptem, tornem-se mais produtivas e mais ágeis. A necessidade de se tornar mais produtivo e competitivo girava principalmente em torno do produto ofertado ao cliente. Agora, o foco vem mudando para o serviço que o cliente espera receber. Os investimentos das empresas têm sido dedicado à modernização dos equipamentos produtivos (instrumentação) e também à revisão e automação de processos de negócio para que consigam atender a essas mudanças de mercado com mais resiliência. Tudo isso seria muito mais difícil e lento se não fosse a TI (Tecnologia da Informação). Quanto mais informatizada a empresa é (com base em processos, metodologia, padrões abertos e governança), mais ágil e flexível ela se torna para reagir aos movimentos do mercado e manter a competitividade e o crescimento. Portanto, sob a ótica de TI, foi necessário adotar novas técnicas de integração de sistemas, novos modelos para organizar as informações, novos processos e estilos de arquitetura, novas formas de desenvolver aplicações, chegando a mudar as necessidades de implementação dos aplicativos (que neste novo contexto representam serviços de negócio), do tradicional ambiente centralizado para o distribuído de fato. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 5 3 Fato: existência de silos e o impacto no negócio Há décadas, cada departamento de grandes empresas tem desenvolvido seus próprios sistemas de aplicações e geralmente com suas próprias bases de dados. Quando a empresa precisa reunir vários departamentos para tomar uma decisão de negócio, descobre que as definições de dados, por exemplo, que cada departamento utilizou são diferentes. Ex.: o que é cliente, nomes de produto etc. Um cliente pode ter várias contas criadas, mas não estão associadas entre si. A inconsistência dos dados e a falta de precisão das informações impedem que a decisão de negócio seja tomada. Apesar dos departamentos terem resolvido eficientemente os problemas com seus sistemas, mesmo que de grande complexidade, nem sempre partilham das mesmas prioridades, objetivos e tipo de tecnologia que os outros departamentos. Existem vários tipos de silos2 que acabam limitando a atuação das empresas no atingimento de seus objetivos de negócio. a. Os silos organizacionais causam atritos entre as diversas prioridades de atendimento; b. Já os silos de informação restringem a visibilidade dos dados necessários para a excelência do serviço; c. Os silos de processo impedem a integração inerente às melhores práticas; d. Outro tipo de silo é o de tecnologia, que impede a integração de dados necessária, para conseguir uma orientação de serviço, e a automação necessária, para direcionar a melhoria de qualidade e custos baixos. Aqui entra a necessidade de adotar as tecnologias adequadas para integração corporativa orientada a serviço e a viabilização da automação dos processos com recursos de software. Figura 3 – Silos organizacionais 2 Silo, neste contexto, quer dizer isolado, sem comunicação com o silo vizinho. O termo foi inspirado nos silos agrícolas, que geralmente são construções cilíndricas fechadas, criadas para armazenar a produção agrícola, como grandes celeiros fechados e isolados. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 6 Silos são verticais por natureza, mas servir o cliente requer uma visão horizontal. Uma das principais estratégias para tornar a empresa mais ágil, flexível, resiliente e eficaz é transpor a barreira dos silos para que a empresa possa se relacionar com seus clientes de forma personalizada e efetiva. A adesão às melhores práticas baseada na arquitetura orientada a serviço possibilita a integração dos silos de informação, processos, pessoas e tecnologia. Portanto, a área de TI consegue entregar serviços de valor às linhas de negócio, com qualidade e confiabilidade. 4 Integração de sistemas Aplicações interessantes raramente ficam isoladas (HOHPE; WOOLF, 2005, p. XXIX). Quando uma aplicação deve fazer interface com outra por uma necessidade de negócio, requer uma comunicação entre as duas, ou seja, uma integração. Toda integração precisa lidar com alguns desafios como: redes não confiáveis ou lentas, aplicações que são diferentes na linguagem, formato de dados ou plataforma onde executa e mudanças que são inevitáveis. A integração da empresa não é uma tarefa simples. Por definição, a integração corporativa precisa lidar com vários aplicativos rodando em múltiplas plataformas e em diferentes localidades. 4.1 Os desafios da integração de sistemas Com a necessidade crescente de integração de vários e diferentes sistemas surgiram também vários problemas técnicos e questões com que os analistas de sistema e desenvolvedores tiverem de se deparar, como: Figura 4 - Desafios da integração de sistemas Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 7 4.1.1 Problemas da integração ponto a ponto Era comum construir integrações para atender às necessidade de negócio, sem planejamento. Consequentemente, o crescimento desordenado de integrações descentralizadas criou uma rede de conexões entre os vários sistemas da empresa. A troca de informação era feita apenas entre dois sistemas, isto é, independentes e separados das demais integrações. Qual seria o impacto se houver a necessidade de mudar a estrutura do registro de contato dos clientes, acrescentando no campo endereço o Twitter, LinkedIn e/ou Facebook3. Como saber o impacto desta mudança? Este modelo de integração ponto a ponto dificulta a implementação de mudanças nos sistemas, formatos de registros e conteúdo das mensagens trocadas entre as aplicações. Figura 5– Conexões ponto-a-ponto entre as aplicações Essas integrações surgiram para atender demandas pontuais e, ao longo do tempo, o volume aumentou tanto que a arquitetura ficou confusa e muito difícil de entender. Imagina a dificuldade para encontrar uma integração que precisa ser atualizada? Por isso, o foco da imagem são as linhas vermelhas que podem aumentar de quantidade rapidamente e trazer dificuldades em termos de flexibilidade e agilidade para atender às novas demandas das áreas de negócio. 3 Twitter, LinkedIn e Facebook são sistemas de colaboração do tipo redes sociais muito populares hoje em dia. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 8 4.1.2 Desafios além dos problemas técnicos Muitos fornecedores de software oferecem soluções de integração com funcionalidades para apoiar a integração entre plataformas, linguagens de programação, como também a habilidade de se integrar com vários pacotes de aplicação mais populares. Porém, os requisitos técnicos de infraestrutura para resolver esses desafios formam uma parte menor dentre as complexidades em torno da integração. a. Os verdadeiros desafios da integração ultrapassam a fronteira entre os problemas técnicos e de negócio. b. A integração corporativa requer mudanças significativas nas políticas da empresa. c. A amplitude do escopo da integração geralmente traz implicações de longo alcance ao negócio. d. O controle limitado dos desenvolvedores sobre as aplicações participantes da integração, legadas ou pacote, muitas vezes não consegue desenvolver diretamente no código, levando-os a criar soluções de contorno. e. A falta de utilização de padrões para integração pelas soluções que implementam a interoperabilidade entre os sistemas. 4.2 Características da integração Os componentes da integração que participam de uma arquitetura de integração são: a. Sistemas – as aplicações ou sistemas que trocarão informações entre si; b. Dados – as informações que vão trafegar entre as aplicações ou sistemas; c. Interface – formato de envio e recebimento das informações entre as aplicações ou sistemas; d. Comunicação – modalidade da comunicação na troca de informações entre as aplicaçõesou sistemas. Se as necessidades de integração fossem semelhantes, haveria apenas um estilo de integração. Existe mais de uma abordagem e os principais tipos de integração são: a. Transferência de arquivo – cada aplicação que precisa compartilhar alguns dados cria um arquivo para ser consumido por outra aplicação e também consome arquivos gerados por outras aplicações; b. Base de dados compartilhada – as aplicações armazenam os dados que querem compartilhar em uma base de dados comum; Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 9 c. Remote Procedure Invocation4 – cada aplicação expõe alguns de seus procedimentos, para que possam ser chamados remotamente, e também chamam procedimentos expostos por outros sistemas para executar a lógica e a troca de informações; d. Mensageria – uma aplicação se conecta a um sistema de mensagens (ou “mensageria”, termo comumente utilizado que veio do inglês “messaging”) comum para trocar informações e mensagens contendo instruções sobre o que deve ser feito com os dados enviados. 4.3 Soluções de integração O alto volume de integrações criadas para atender à demanda dos negócios transformou a arquitetura de integração em “espaguete” (termo utilizado para expressar a quantidade muito alta de integrações ponto a ponto entre sistemas). O surgimento da internet na década de 1990 mostrou o poder dos padrões abertos quando aplicados a arquiteturas cliente-servidor. Isso criou as condições para o desenvolvimento dos padrões Web Services. Portanto, as soluções de integração chegaram para fundamentar a arquitetura orientada a serviços com: padrões (XML); componentes de software (Web Services) e a evolução de modelos de arquitetura (ponto a ponto; Hub-Spoke e Pipeline). 4.3.1 Tecnologia Como forma de lidar com os problemas de integração, começaram a surgir no mercado novos padrões e tecnologias inovadoras. Dentro das mais importantes, podemos referir: • XML – vem do termo em inglês eXtensible Markup Language. Esta tecnologia foi criada pela W3C (World Wide Web Consortium). O XML começou a se popularizar no fim da década de 1990 durante o movimento do eBusiness, que demandou o uso de linguagens de escrita (script) no lado do servidor para viabilizar os negócios das empresas via internet. O XML permite anexar significado e contexto para qualquer parte da informação transmitida através de protocolos de internet. Apresenta dados como arquivos de texto simples para facilitar a leitura da informação. Este padrão viabilizou a tão desejada interoperabilidade aberta. 4 Remote Procedure Invocation é uma tecnologia conhecida como chamada remota de procedimento, que permite a uma aplicação chamar e executar um procedimento em outro sistema. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 10 • WebServices – é um componente de software criado com uma interface pública que permite às aplicações enviar e receber dados em formato XML. Tecnologia que permite que diferentes aplicações possam se comunicar entre si usando os protocolos HTTP e HTPPS, ainda que em plataformas distintas ou desenvolvidas em linguagens diferentes. Permite ainda incorporar dentro das mensagens protocolos de autenticação, autorização e encriptação. 4.3.2 Arquiteturas de integração Até o momento, falamos sobre a arquitetura ponto a ponto, que traz limitações para as empresas. Este cenário ainda é simples. É possível entender as integrações pré-espaguete. Figura 6 – Arquitetura ponto a ponto Fonte: Adaptada de Redbooks (2002, p. 11). Existem diferentes produtos/arquiteturas que trouxeram inovações relevantes dentro da área de integração de sistemas ou EAI (Enterprise Application Integration): • Arquitetura Hub-Spoke5 – faz uso de um broker ou de um componente que centraliza o processamento de mensagens (o Hub, que neste caso seria um centro) e de vários adaptadores que se conectam com as diferentes aplicações (Spoke, que seriam as terminações). Assim, o broker ficaria responsável pela transformação, segurança e roteamento das mensagens para os adaptadores que se conectariam e enviariam as mensagens propriamente ditas para as aplicações. Existem ainda hoje várias soluções no mercado que cumprem com esta arquitetura de sistemas, a qual demanda alguma especialização no desenvolvimento, mas, enquanto solução fechada e integrada, o seu uso é relativamente simples. 5 Hub-spoke é um termo inglês que nasceu inspirado no modelo de distribuição de pacotes em voos americanos para otimizar a logística. Este modelo consiste em um aeroporto central (hub) e os voos para outros aeroportos como se fossem raios de uma roda de bicicleta (spoke). Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 11 Figura 7 – Representação gráfica de uma arquitetura Hub-Spoke Fonte: Adaptada de Redbooks (2002, p. 12). • Arquitetura Pipeline ou BUS – esta arquitetura se parece bastante com a anterior por seguir as mesmas características. No entanto, possui uma interessante diferença: os componentes de transformação e roteamento estão distribuídos também pelos adaptadores. Pelo fato de os adaptadores processarem mensagens na mesma plataforma da aplicação para a qual foram criados, é possível ter um plano de escalabilidade melhor, pois os serviços podem ficar distribuídos entre as plataformas participantes do ambiente. Isso evita a necessidade de acrescentar recursos em um servidor central. Outra diferença que podemos destacar é o uso de tipos de mensagens padronizadas e tecnologias abertas, além dos produtos Hub-Spoke que fazem parte desta arquitetura também. Figura 8 – Arquitetura Pipeline Fonte: Adaptada de Hohpe e Woolf (2005, p. 54). • Arquitetura Orientada a Serviço – esta arquitetura diferencia-se das anteriores porque os processos de negócio e as aplicações já não são codificados como estruturas complexas de programas, mas são orquestrados através das chamadas de serviço, de forma distribuída e independente. As empresas que adotaram a arquitetura orientada a serviço há alguns anos observam hoje resultados refletidos em seus negócios, tanto na agilidade de resposta ao mercado quanto na flexibilidade para criar novos serviços e se adaptar a mudanças que, às vezes, o mercado impõe. ftp://www.redbooks.ibm.com/redbooks/ITSO%20WebSphere%20Forum/bi/BI07.pdf Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 12 Figura 9 – Arquitetura de Referência SOA Fonte: The OpenGroup6 (2015). Estas tecnologias que exploramos representam algumas soluções que foram incorporadas em SOA, mas não as únicas. Na verdade, a SOA pode ser considerada uma evolução natural e especializada do mundo de TI na forma de paradigma7. Considerações finais Podemos, então, considerar que a arquitetura orientada a serviços surgiu como uma solução em resposta aos problemas atuais das empresas. Ela se apresenta mais holística do que as abordagens comuns, pois representa um avanço não só tecnológico (reaproveitando um conjunto integrado de novas tecnologias), mas também conceitual. Ela é importante para que seja possível resolver não só problemas de integração de sistemas, mas, sobretudo, para alavancar a dinâmica de negócio das empresas. Referências ERL, Thomas. SOA: Princípios de design de serviços. São Paulo: Prentice Hall, 2008. ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Indiana - EUA, 2005. 6 OpenGroup é um consórcio global que viabiliza o atingimento dos objetivos de negócio através de padrões de TI (especificações de padrões abertos). 7 Paradigma pode ser uma abordagem a algo, uma escola de pensamento com relação a algo ou um conjunto combinado de regras aplicadas dentro de um limite predefinido. ERL, Thomas. SOA: Princípios de design de serviços. São Paulo: Prentice Hall, 2008. p. 19 Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 13 HURWITZ, Judith; BLOOR, Robin; KAUFMAN,Marcia; HALPER, Dra. Fern. Arquitetura Orientada a Serviços – SOA para Leigos. Rio de Janeiro, 2009. HOHPE, Gregor; WOOLF, Bobby. Enterprise Integration Patterns. Boston: Pearson Education Inc., 2005. OPENGROUP: <https://www.opengroup.org/soa/source-book/soa_refarch/services.htm>. Acesso em: 15 julho 2015.REDBOOKS. International Technical Support Organization. Using Web Services Technology for Enterprise Application Integration: Session BI07. La Hulpe, Belgium: IBM International Education Center, 2002. Disponível em: SOA and web services: <https://www. ibm.com/developerworks/webservices/>. Acesso em: 15 julho 2015. <ftp://www.redbooks.ibm.com/redbooks/ITSO%20WebSphere%20Forum/bi/BI07.pdf>. Acesso em: 25 jul. 2015. THE OPENGROUP. SOA reference architecture technical standard: services layer. Disponível em: <https://www.opengroup.org/soa/source-book/soa_refarch/services.htm>. Acesso em: 15 jul. 2015. WOOLF, B. Exploring IBM SOA Technology & Practice: How to Plan, Build and Manage a Service Oriented Architecture in the Real World. EUA, 2008. https://www.opengroup.org/soa/source-book/soa_refarch/services.htm https://www.ibm.com/developerworks/webservices/ https://www.ibm.com/developerworks/webservices/ Arquitetura Orientada a Serviço Aula 02 Utilização de SOA visando à flexibilidade nos negócios Objetivos Específicos • Demonstrar como SOA suporta a flexibilidade nos negócios, garantindo menor impacto em alterações de regras de negócio. Temas Introdução 1 Orientação a serviços 2 Vantagens da computação orientada a serviços Considerações finais Referências Mikiko Ishida Professor Autor Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 2 Introdução Nesta aula vamos começar a entender como podemos viabilizar os benefícios que a arquitetura orientada a serviços nos oferece. Esta abordagem é resultado de uma coleção de conhecimentos e experiências anteriores que motivaram o surgimento de novos princípios de construção (design), além de manter algumas práticas e tecnologias já existentes. A proposta de SOA é muito interessante, mas podemos perceber que a sua implemen- tação deve ser algo realizado com base em boas práticas, já identificadas e publicadas pelos profissionais mais experientes no mundo todo e que nos ajudam a começar de forma mais organizada e não do zero. Em inglês há uma expressão muito utilizada quando estamos em uma situação como esta, ou seja: se quero adotar a arquitetura orientada a serviço, é importante estudar bem, antes de começar, porque “não há almoço grátis” (“There’s no free lunch”). Porém, a afirmação de Thomas Erl (2008, p. 2), “[...] a chave para se fazer algo com sucesso é entender o que se está fazendo”, reflete bem a chave do segredo e vale para qualquer projeto que queremos ter sucesso. O principal objetivo do esforço em utilizar a arquitetura orientada a serviço é produzir uma coleção de serviços padronizados e aderentes às necessidades de negócio da empresa. A SOA estabelece um modelo de arquitetura que visa a melhorar a agilidade, a flexibilidade, a eficácia e a produtividade de uma empresa, e os serviços são os principais viabilizadores dos objetivos estratégicos que estão associados à computação orientada a serviços1. 1 Orientação a serviços A orientação a serviço é um paradigma de construção e integração de soluções de software compostas por elementos modulares chamados serviços. O paradigma baseia-se nos princípios de orientação a serviços (FUGITA; HIRAMA, 2012, p. 7) que serão descritas a seguir. Serviço sempre existiu na história da humanidade. Qualquer pessoa que executa um trabalho ou função para apoiar o outro está prestando ou fornecendo um serviço. Isso vale para um grupo de indivíduos que realiza tarefas coletivamente para dar apoio a um trabalho maior. Uma empresa que executa funções ou tarefas associadas aos objetivos do seu negócio também está fornecendo serviços. Um serviço é uma tarefa bem definida composta por diversas operações2 e que pode ser relativamente isolada de outras tarefas. Para que um 1 Computação orientada a serviço é o ambiente já adequado para a lógica que foi projetada de acordo com os princípios de design da orientação a serviços, incluindo as novas tecnologias e plataformas. 2 Operações referem-se às operações de lógica codificada no serviço. Fazendo uma analogia com a orientação a objetos, as operações estão para um serviço assim como os métodos estão para uma classe. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 3 grupo de prestadores de serviços individuais possa fornecer coletivamente um serviço maior, cada indivíduo precisa ter características fundamentais e comuns, como disponibilidade, confiabilidade e capacidade de se comunicar utilizando a mesma linguagem. Assim, esses indivíduos formam uma equipe funcional produtiva. O principal objetivo da orientação a serviços é estabelecer esses requisitos básicos. No contexto da arquitetura orientada a serviço, o termo “serviço” é específico e se refere a uma combinação única de características de projeto (design). À medida que os serviços (lógica) são projetados repetidamente com essas características comuns, a orientação a serviços se torna uma realidade em todo o ambiente, assim como move a empresa para um estado em que sua lógica se torna cada vez menos dependente e mais agnóstica em relação a qualquer processo de negócio. Como resultado, aumenta amplamente o potencial de reuso desses serviços. No contexto de automação de negócios, um paradigma de design é uma abordagem que rege o desenho ou projeto de lógica de solução. A teoria de engenharia de software conhecida como separação de preocupações (separation of concerns) é aplicada na construção de uma lógica distribuída. Esta teoria afirma que um problema maior deve ser decomposto em um conjunto de problemas menores ou de “preocupações” menores, ou seja, em unidades de lógica que resolvem cada preocupação. A resolução de cada unidade, na composição, acaba resolvendo o problema maior. O principal benefício dessa forma de solucionar os problemas é que as unidades de lógica projetadas para resolver os interesses imediatos permanecem agnósticas em relação ao problema maior. 1.1 Princípios de construção (design) Uma empresa pode possuir um único portfólio de serviços compartilhados entre todas as áreas ou construir diversos portfólios de serviços de domínio para cada área (ERL, 2008). Para entender o que é o portfólio de serviços compartilhados, veja a definição de Fugita e Hirama (2012, p. 21): Um portfólio de serviços consiste em um conjunto de serviços que, de forma coletiva, representam funções lógicas de uma organização ou domínio. Serviços pertencentes a um mesmo portfólio devem formar um conjunto coeso onde as funções de um serviço complementam os demais e todos os serviços seguem os mesmos padrões de design, realização e implementação. Para se construir um portfólio de serviços compartilhados, a empresa deve desenvolver os diversos projetos de soluções orientadas a serviços com base nos princípios de construção (design), pois a aplicação deste paradigma nas atividades de modelagem, análise e design resulta em uma coleção de lógicas que pode ser realmente classificada como “orientada a Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 4 serviços” e unidades de lógica como “serviços”. Portanto, a seguir, vamos conhecer esses princípios da orientação a serviços. 1.1.1 Contrato de serviço padronizado Um serviço expressa o seu propósito e suas capacidades (funcionalidades) através de um contrato de serviços. O contrato inclui a interface técnica pública de um serviço, a natureza e a quantidade do conteúdo que será publicado, representando um acordo formal firmado entre o provedor do serviço e seus consumidores. O contrato de serviço deve disponibilizar as informações sobre a localização do serviço, as operações executadas,as mensagens de entrada e saída utilizadas pelo serviço, as regras para a sua utilização e eventualmente os detalhes semânticos (significados) das operações do serviço. 1.1.2 Baixo acoplamento de serviço Acoplamento significa ligação entre dois elementos. No contexto da orientação a serviço, utilizamos esse conceito como uma medida do nível de dependência entre os serviços. O princípio do baixo acoplamento de serviço permite que o design e a lógica de um serviço possam evoluir independentemente de sua implementação, ainda que a interoperabilidade básica com os consumidores do serviço seja garantida. Portanto, mesmo que um serviço seja modificado, evoluído ou substituído ao longo do tempo os consumidores não sofrerão impacto. Existem muitos tipos de acoplamento envolvidos na construção de um serviço e para alcançar o nível adequado, devem ser avaliadas as opções de design de serviço que possam atender com equilíbrio. 1.1.3 Abstração de serviço Abstração é o encapsulamento da lógica interna de um serviço por meio de sua interface. Esse princípio enfatiza a necessidade de ocultar o maior número possível de detalhes subjacentes de um serviço, mantendo o relacionamento com um nível baixo de acoplamento. Os níveis de abstração aplicados ao serviço podem afetar a granularidade do contrato de serviços e influenciar o custo final e o esforço de administração. Quanto mais funcionalidade é encapsulada em um serviço, mais alta a granularidade deste serviço. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 5 Figura 1 – Natureza da lógica e da implementação de um serviço encapsulado Fonte: Adaptada de Erl (2008, p. 137). 1.1.4 Capacidade de reuso Na orientação a serviço, cada serviço é projetado para ser reusável, mesmo que não haja requisitos específicos para isso no momento em que é desenvolvido. O serviço deve ser projetado considerando as várias formas de reuso como: transação entre aplicações; composição de serviços e processos de negócio; e uso como serviço utilitário. Quanto mais alto o nível de granularidade de um serviço, menores são as possibilidades de se usar em mais de um processo de negócio. Exemplo: um serviço de gestão de clientes tem um nível de granularidade mais alta do que o serviço de cadastro de cliente. O primeiro pode incluir outros serviços (composição) e conter informações de gestão de relacionamento em sua lógica. Já o segundo é um serviço com nível de granularidade menor e poderia ser usado para cadastrar funcionários e/ou terceirizados. Este é o princípio mais enfatizado na orientação a serviços e é importante na análise de serviços e processos de design. Posiciona os serviços como recursos corporativos com contextos funcionais agnósticos. Existem variações e níveis de reuso, assim como modelos de serviço agnóstico associado. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 6 Figura 2 – Fusão do projeto do produto comercial com os métodos corporativos tradicionais Fonte: Adaptada de Erl (ServiceOrientation.com, disponível na Midiateca da disciplina, 2015, s.p.). 1.1.5 Autonomia de serviço A autonomia representa a capacidade de se autogovernar ou autocontrolar. Para que os serviços realizem suas capacidades de modo consistente e confiável, sua lógica precisa ter um grau significativo de controle sobre o seu ambiente e recursos. Por isso, questões relacionadas ao desenho da lógica e ao ambiente de implementação real do serviço são levantadas. Este princípio suporta a realização dos outros princípios de construção (design) nos ambientes reais de produção, fortalecendo as características de projeto que aumentam a confiabilidade e a capacidade de prever o comportamento de um serviço. Um serviço será capaz de realizar sua lógica, independentemente de influências externas, e deve ter o controle para se governar no ambiente de execução (runtime). 1.1.6 Independência de estado do serviço O estado refere-se à condição em que se encontra em um determinado momento. Um trem que está se movendo para a próxima estação está em estado de movimento, enquanto que o que está parado em uma estação está no estado estacionário. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 7 No contexto de orientação a serviço, geralmente um programa de software em execução pode passar por diferentes estados e as variações das informações de estado tendem a ser temporárias. Os tipos de condições e dados de estado podem ser: estados ativos e passivos; condições com e sem informações de estado; dados de estado de contexto, de sessão e de negócio; dados de contexto e regras de contexto. Este princípio ajuda no aumento da escalabilidade do serviço, dá suporte ao design de lógica agnóstica e aprimora o potencial de reuso do serviço. 1.1.7 Visibilidade do serviço Os serviços precisam ser facilmente identificados e visíveis, para que sejam descobertos e acessados pelos consumidores. Outro objetivo comum é permitir a busca de serviços que poderiam já ter as funcionalidades necessárias para reusá-los, caso contrário, seria necessário criar novos serviços. As informações mais úteis que buscamos são: o propósito, as capacidades e as limitações de capacidades do recurso, para avaliar se será possível reusá-lo ou não. Portanto, este princípio visa a posicionar os serviços como recursos altamente visíveis dentro da empresa e com informações claras sobre estes para a correta interpretação. 1.1.8 Composição de serviços Na evolução de TI, a composição foi uma inovação fundamental para a área de design e tornou-se comum na arquitetura de solução personalizada, no design de produtos de softwares comerciais e principalmente sistemas operacionais. A capacidade de compor efetivamente os serviços é um requisito crucial para alcançar alguns dos objetivos mais fundamentais da computação orientada a serviços. Este princípio diz que os serviços devem ser componíveis3. A composição de serviços é uma forma de reuso de serviços, assim como o reuso possibilita a composição de serviços em larga escala. Se uma empresa adota estes princípios de design e estabelece uma coleção lógica de serviços representada por um portfólio de serviços altamente reusáveis, uma grande quantidade de novos requisitos da automação de negócios pode ser atendida através da composição de serviços. 3 Componível é no sentido de poder compor, ou seja, possibilidade para criar uma composição. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 8 Figura 3 – Teoria da separação das preocupações Fonte: Adaptada de Erl (ServiceOrientation.com, disponível na Midiateca da disciplina, 2015, s.p.). 1.2 Interoperabilidade A interoperabilidade não foi classificada como um princípio porque é uma característica de projeto fundamental para promover a aplicação de cada um dos oito princípios relacionados acima. A interoperabilidade entre os serviços é básica e deve ser possível independentemente da tecnologia utilizada em sua implementação. Para que os princípios da orientação a serviços sejam realizados com consistência e êxito, devem ser analisados os fatores ambientais, como a compatibilidade de protocolos de comunicação, o nível de maturidade da plataforma tecnológica e a adesão aos padrões de tecnologia. Cada um dos oito princípios suporta e contribui para a interoperabilidade com o objetivo de torná-lo um subproduto natural até que o nível de interoperabilidade intrínseca ou inerente seja uma característica de design de serviço comum e esperada. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 9 2 Vantagens da computação orientada a serviços A computação orientada a serviços representa uma nova geração da plataforma da computação distribuída. Ela inclui o paradigma da orientação a serviços e a arquitetura orientada a serviços, com o objetivo fundamental de criar e montar um ou mais portfólios de serviços (ERL,2008, p. 26). A visão da computação orientada a serviço é bastante ambiciosa e também muito atraente para as empresas que querem aprimorar a eficácia de sua área de TI. Por isso, é importante entender os problemas já enfrentados pelas comunidades de fornecedores e de usuários finais dentro da indústria de TI durante a implementação da plataforma de computação orientada a serviços. A partir destas experiências surgiu um conjunto de objetivos e benefícios comuns que foram percebidos e que definem uma “receita” de sucesso na adoção da orientação a serviços pelas empresas. Segundo Erl (2008, p. 35), os sete objetivos identificados estão relacionados entre si e podem ser classificados em objetivos estratégicos, e três deles, além de serem objetivos, são também benefícios resultantes. a. Maior interoperabilidade intrínseca – a interoperabilidade é uma característica de sistemas capazes de se comunicar com outros para compartilhar dados. Na orientação a serviços a interoperabilidade é nativa nos serviços criados com a aplicação dos princípios e padrões de design para reduzir a necessidade de integração. Algumas das características de design requeridas para facilitar a interoperabilidade dos serviços são: padronização, escala, previsibilidade de comportamento e confiabilidade dos contratos. À medida que os serviços são produzidos em projetos e em momentos distintos, eles podem ser agrupados em várias configurações de composição para automatizar diferentes tarefas de negócio. b. Maior federação – federação é unir coisas diferentes para que elas possam agir como uma. Os recursos de TI e os aplicativos podem ser unidos, ainda que se mantenha a autonomia individual e a autogovernança. A federação em SOA permite aumentar as implementações em larga escala de serviços padronizados e capazes de se compor. É possível atingir um nível mais alto de federação se utilizarmos a tecnologia Web services para construir as soluções orientadas a serviços, ou seja, aplicando os princípios de padrões e de design. c. Mais opções de diversificação de fornecedores – todos nós queremos escolher inovações tecnológicas e produtos do “melhor fornecedor da categoria” e também queremos utilizá-los conjuntamente com os recursos que já existem na empresa. Para que a empresa possa ter esta opção de escolha, é importante que a arquitetura da tecnologia a ser adquirida não esteja associada ou atada à plataforma de um fornecedor específico. Isso dá liberdade à empresa de mudar, ampliar ou substituir Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 10 algumas soluções sem interromper toda a arquitetura de serviço federada. Os Web services reduzem ainda mais a dependência das plataformas de fornecedor porque não impõem requisitos de comunicação proprietária. Assim, o tempo de vida da solução é prolongado e o retorno sobre o investimento é aumentado. d. Maior alinhamento do domínio de negócio e de tecnologia – era comum a falta de precisão na transformação dos requisitos de negócio em implementação da lógica de uma solução. Graças ao paradigma de design, que promove a abstração em vários níveis, é possível aplicar a abstração funcional em camadas de serviço que encapsulem e representem precisamente os modelos de negócios. e. Maior retorno sobre o investimento (ROI4) – a complexidade da natureza da lógica dos aplicativos aumentou, as arquiteturas ainda não são federadas e o processo de integração ainda crescente: esses são os inibidores para que um departamento de TI se mantenha e evolua, sem que ele represente um valor significativo no orçamento operacional total de uma empresa. A utilização de lógica de solução agnóstica que possa atender a vários objetivos e ser reusável tira proveito da natureza de interoperabilidade inerente nos serviços criados sob os princípios de design. f. Maior agilidade organizacional – a agilidade empresarial está relacionada à eficiência com que a empresa responde às mudanças de mercado. Muitas vezes o departamento de TI é visto como um “gargalo” que dificulta a capacidade de resposta desejada, pois exige tempo e recursos demasiados para atender a novos requisitos de negócio. À medida que o portfólio de serviços é composto por uma porcentagem maior de serviços agnósticos, estes podem ser posicionados como ativos de TI reusáveis, e que podem ser repetidamente compostos em diferentes configurações. Portanto, o tempo e o esforço necessários para automatizar novos processos de negócio ou modificar algum existente são reduzidos proporcionalmente. g. Menor carga de trabalho de TI – o departamento de TI de uma empresa que aplica consistentemente a orientação a serviços ao longo do tempo apresenta menor desperdício e redundância, menor tamanho e custo operacional e menos despesas indiretas associadas à governança e evolução. Portanto, uma TI mais ágil e mais enxuta que contribui mais para os objetivos estratégicos da empresa. 4 ROI vem do termo em inglês Return Of Investment, ou seja, retorno sobre o investimento. Aqui no Brasil é muito utilizado em inglês mesmo. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 11 Figura 4 – Representação dos objetivos e benefícios de SOA Fonte: Adaptada de Erl (2008, p. 35). Para concluir o entendimento desses oito objetivos e benefícios, segue o resumo dos pontos-chave de Erl (2008, p. 40): Os benefícios-chave da computação orientada a serviços estão associados com a padronização, a coerência, a confiabilidade e a escala estabelecidas dentro dos serviços por meio da aplicação dos princípios de design da orientação a serviços. A plataforma de computação orientada a serviços fornece o potencial de aumentar a capacidade de resposta e a rentabilidade econômica da TI por meio de um paradigma de design que enfatiza os objetivos e benefícios estratégicos. Considerações finais Nesta aula foi possível entender como é possível obter os benefícios tão atraentes da arquitetura orientada a serviço. Benefícios estes que impactam positivamente os negócios de uma empresa. Mas, lembre-se, “não há almoço grátis” para se obter o sucesso. Devemos entender os objetivos que se quer alcançar, estudar e planejar para saber como fazer e seguir os princípios da orientação a serviços que ajudarão a reduzir os riscos e manter a governança, a produtividade, a flexibilidade e a escalabilidade do processo como um todo. Independentemente da escolha de começar com uma única iniciativa para construir o portfólio (neste caso com investimento inicial mais alto) ou várias iniciativas em uma abordagem incremental, esta é uma jornada muito estimulante que integrará a empresa toda e o deixará preparado para incluir novos projetos inovadores com mais agilidade graças à arquitetura adotada. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 12 Ao atingir a maturidade na adoção da arquitetura orientada a serviço, a empresa se tornará mais competitiva graças à sua agilidade, resiliência5 e responsividade6 ao mercado. Os resultados serão parecidos com os percebidos por muitas outras empresas do mercado, que estão usufruindo o sucesso. Referências ERL, Thomas. Service Orientation: Service-Orientation Design Principles. Disponível em: <http://serviceorientation.com/serviceorientation/index>. Acesso em: 15 jul. 2015. ______. SOA: Princípios de design de serviços. São Paulo: Prentice Hall, 2008. FUGITA, Henrique Shoiti; HIRAMA, Kechi. SOA: modelagem, análise e design. Rio de Janeiro: Elsevier, 2012. Imagem Fusão do projeto: ERL, Thomas. Service Orientation. Disponível em: <http:// serviceorientation.com/serviceorientation/service_reusability>. Acesso em: 15 jul. 2015. Imagem Teoria da separação das preocupações: ERL, Thomas. Service Orientation. Disponível em: <http://serviceorientation.com/serviceorientation/service_composability>. Acesso em: 15 jul. 2015. 5 Resiliência é usada neste contexto para definir a capacidade de umaempresa não “sentir tanto” o impacto de um evento negativo no mercado, por estar organizada de forma que consegue absorver com menos “dor”. 6 Responsividade é usada para expressar a capacidade da empresa em responder rápido ao mercado quando há oportunidades não previstas. Responder inclui perceber logo e agir no contexto da oportunidade. Arquitetura Orientada a Serviço Aula 03 Fundamentos da SOA: Arquitetura Distribuída e Sistemas de Softwares Objetivos Específicos • Identificar os tipos de softwares existentes e compreender como a SOA integra aplicações de tecnologia distintas. Temas Introdução 1 Saindo do modelo de silos para a arquitetura distribuída 2 A computação distribuída 3 A importância da criação de padrões 4 Softwares importantes para a SOA Considerações finais Referências Mikiko Ishida Professor Autor Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 2 Introdução Como chegamos à arquitetura orientada a serviço? De aplicações monolíticas à arquitetura de sistemas distribuídos até chegar à arquitetura orientada a serviço. Como foi possível? Quais são os softwares1 ou tecnologias que ajudam a aplicar realmente os princípios da orientação a serviços? Nesta aula, vamos voltar um pouco no tempo e ver as respostas a essas perguntas e também entender como tudo se encaixa através da arquitetura de software, que viabiliza a implementação das regras, as quais devem ser cumpridas para que a orientação a serviços e seus princípios sejam continuamente aplicados. 1 Saindo do modelo de silos para a arquitetura distribuída No início da Tecnologia da Informação, o “usuário” (quem solicitava um sistema para automatizar ou resolver um problema) explicava quais funcionalidades queria e o programador anotava o que entendia para começar a codificar o programa, sem criar uma arquitetura. À medida que os negócios evoluíram e os requisitos aumentaram, os programadores criaram estruturas sistemáticas para organizar os programas e o negócio. Assim começou a arquitetura, no começo, qualquer design básico de um sistema era conhecido como uma arquitetura. Ao descrever uma estrutura de software, os princípios de design fundamentais aplicados são chamados de “arquitetura de software”. A ideia da arquitetura implica em um planejamento de acordo com um conjunto de diretrizes e regras. Uma boa arquitetura de software especifica como os dados são armazenados, como os usuários interagem com o sistema, como os programas se comunicam e assim por diante. Na ciência da computação, a arquitetura descreve o design geral e a estrutura de um sistema de computador. Já os diagramas de arquitetura de software descrevem os componentes de um sistema de computação, oferecendo indicação de como eles se conectam e interagem (HURWITZ et al., 2009, p. 45). Na época dos silos, as empresas ou governos tinham aplicações de software especializadas para executar funções de negócio, por exemplo, receber e executar um pedido de cliente. Porém, a otimização dos processos de negócio demandou a necessidade de interagir com outros sistemas para acessar informações de locais diferentes. A necessidade de integrar outros sistemas implicava em altos custos e esforços, levando muitas vezes os programadores a criarem novos códigos para resolver o problema, por exemplo, criando uma base replicada de outro sistema, o que, consequentemente, resultou em mais silos. Veja a seguir uma figura ilustrativa (Figura 1) para entender o que acontecia com uma aplicação. 1 Softwares são programas de computador, as estruturas de dados e a documentação associada juntos. Os softwares podem ser: sistema básico: do tipo editor, compilador, sistemas operacionais, drivers; aplicação ou aplicativo: controla os negócios e processos; embutido; Web e legado. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 3 Figura 1 – Aplicação monolítica – todos os tipos de operação em um bloco autocontido Fonte: Adaptada de IBM (2015). 2 A computação distribuída A computação distribuída surgiu para atender à necessidade de integração entre sistemas que estão em computadores de locais diferentes, para realizar uma tarefa de negócio. É um termo que descreve uma arquitetura de hardware e software em que mais de um computador participa da realização de determinada tarefa. Veja como Pulier e Taylor (2008, p. 7) descrevem a computação distribuída. Cada computador que participa da execução da tarefa de negócio deve ser apto a se comunicar com o outro computador ou outros computadores envolvidos na tarefa. E como os computadores em ambiente distribuído se comunicam? As máquinas podem se comunicar através de uma variedade de métodos, da Internet à Rede de Longa Distância (WANs2) ou Redes Locais (LANs3) dedicadas. Virtualmente, mensagens são a fonte de todas as questões e soluções relacionadas ao gerenciamento de computação distribuída. A troca eletrônica de dados (EDI4), a integração de aplicações corporativas (EAI5) ou outras formas com as quais os fornecedores de TI tentam resolver os desafios da computação distribuída realizam a transmissão, o recebimento e a resposta a mensagens entre os computadores envolvidos para solucionar a necessidade de integração. 2 WAN vem do termo em inglês, Wide Area Network. 3 LAN vem do termo em inglês, Local Area Network. 4 EDI vem do termo em inglês, Electronic Data Interchange. 5 EAI vem do termo em inglês, Enterprise Application Integration. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 4 Já o Web service é uma evolução dessas técnicas utilizadas para transmitir mensagens entre computadores em ambientes distribuídos e mais, com padronização. 2.1 Problemas da interoperabilidade Geralmente, os computadores eram de diferentes fabricantes com diferentes sistemas operacionais, que rodavam vários softwares escritos também de forma diferente e por equipes distintas. Ou seja, as informações não eram entendidas e nem transmitidas de forma compatível. Os sistemas precisavam de um “tradutor” entre eles, ou seja, uma interface. Uma interface é como um software (intermediário), que interpreta e transmite mensagens entre dois computadores que estão operando em uma arquitetura distribuída, representada na Figura 2. E é claro que esta interface precisa estar disponível para que esta comunicação aconteça. Porém, a partir do uso de interfaces alguns problemas surgiram. Figura 2 – Primeira forma de integração – início da computação distribuída Fonte: Adaptada de Pulier e Taylor,(2008, p. 9). Na computação distribuída, as interfaces de software servem como intermediárias de processamento de mensagens entre computadores que precisam se comunicar. Algumas características das interfaces desta época são: a. Padrões proprietários – a utilização de interfaces feitas sob medida começou a crescer. Quando havia necessidade de criar uma comunicação entre um sistema e o outro, ao tentar reutilizar a interface já existente, verificava-se que não atendia totalmente à necessidade e o programador geralmente decidia escrever outra interface específica para o novo problema que estava sendo solucionado. Com isso, o volume de interfaces do tipo sob medida aumentou, contendo padrões proprietários e funções redundantes. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 5 b. Acoplamento forte – a adição de novos computadores a uma interface existente que trabalha com padrão proprietários adiciona mais código proprietário e cria uma arquitetura de integração fortemente acoplada (Figura 3). E a cada novo sistema que precisar se comunicar com estes já existentes, precisará criar um programa de interface de software para estabelecer a conectividade. Qualquer mudança que seja requerida neste cenário implica em gastar muito tempo e dinheiro. Cada computador tem suas próprias “fechadura e chave” para transmitir e receber mensagens. Neste contexto, a expressão“fechadura e chave” faz uma analogia ao conjunto de TI: sistema operacional, linguagem de programação e protocolos de comunicação. Figura 3 – Forte acoplamento devido às interfaces com padrão proprietário Fonte: Adaptada de Pulier e Taylor (2008, p.10). Houve desespero em muitas empresas por causa de interfaces caras, proprietárias ou customizadas. Bilhões de dólares foram despendidos, afetando os caixas e até os valores de ações de várias companhias do mundo. Esses problemas são o resultado de uma condição em que os negócios precisavam utilizar numerosos computadores diferentes para realizar as tarefas, porém, sem um padrão comum para tornar o processo eficiente. Todos entendiam que era necessário criar padrões para as mensagens entre os computadores. Para isso, os grandes fornecedores que desenvolviam um conjunto de tecnologias para as suas próprias plataformas precisavam entrar em um acordo e participar da definição dos padrões que seriam utilizados por todos. E foi o que aconteceu. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 6 2.2 O advento da orientação a objeto Enquanto as organizações se tornavam cada vez mais alicerçadas na informação, surgia uma maior necessidade de sistemas. O problema não era o hardware, pois este evoluía rapidamente, aumentando o seu poder de processamento a uma velocidade incrível. O problema era o software, pois construir um software que pudesse aproveitar a capacidade de processamento dos poderosos computadores era um grande desafio. O processo de desenvolvimento de softwares era muito lento e geralmente acabava custando acima do orçamento. Esta situação ficou conhecida como a “crise do software”. Assim, chegou-se à abordagem do software orientado a objetos, que proveu a base para um passo importante em direção ao framework conceitual para os sistemas distribuídos interoperáveis. Pois, a orientação a objetos é um modelo de análise, projeto e implementação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas de objetos. Para quem quiser conhecer, há um livro já antigo, mas muito interessante, que compara o objeto com uma célula orgânica em vários aspectos como: encapsulamento de dados e comportamento, a comunicação via mensagens, a constituição por blocos, a hierarquia dos tipos de células com a hierarquia de objetos etc. O livro é o seguinte: TAYLOR, David A. Object- Oriented Technology: A Manager’s Guide. EUA: Addison-Wesley, 1990. A orientação a objetos introduziu vários conceitos que depois foram adotados pela orientação a serviços. Um dos objetivos da computação orientada a objetos era alcançar a reutilização e baixar o custo do desenvolvimento de aplicações. Porém, o fato de não haver um software orientado a objetos multilinguagem universal não incentivava os programadores a reutilizar os códigos existentes. Isso porque mesmo que encontrasse um código para reuso, poderia estar em outra linguagem não compatível com o sistema operacional onde rodará este sistema. Com isso, não obtiveram a interoperabilidade desejada entre sistemas e a utilidade do reuso ficou limitada até a chegada dos Web services. Veja como Pulier e Taylor definem Web services de forma abrangente: Os Web services disponibilizam funcionalidades maiores como componentes de software reutilizáveis que podem interoperar entre diferentes linguagens de programação, elevando assim, o conceito de reutilização a novos patamares, eliminando potencialmente as dificuldades de interfaces proprietárias ou customizadas que conectam um sistema a outros. (PULIER; TAYLOR, 2008, p. 16). Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 7 2.3 O surgimento da arquitetura cliente-servidor A área de Tecnologia da Informação avançou novamente com o surgimento da computação cliente-servidor. Cliente-servidor descreve uma arquitetura de software em que um programa de computador (o cliente) solicita dados ou funcionalidade de outro software, geralmente em um computador remoto, que é conhecido como servidor (PULIER; TAYLOR, 2008, p. 16). Esta arquitetura está exemplificada na Figura 4: Figura 4 – Exemplo de transação CLIENTE-SERVIDOR A arquitetura cliente-servidor é a essência do Web services e da arquitetura orientada a serviços. A geração de arquitetos e desenvolvedores de softwares aprenderam a observar as vantagens de se criar sistemas distribuídos baseados em mensagens. Com o surgimento da internet, ficou mais claro o poder dos padrões abertos quando aplicados à arquitetura cliente- servidor, e desta forma foram criadas as condições para o desenvolvimento dos padrões de Web services. 3 A importância da criação de padrões Na Tecnologia da Informação, os órgãos padronizadores são grupos industriais colaborativos sem fins lucrativos que desenvolvem e publicam os padrões que são utilizados para se desenvolver tecnologia. Existem vários órgãos padronizadores, mas os mais impor- tantes a se destacar neste momento são: o W3C (Web Services Interoperability Organization – WS-I) e o OASIS (Organization for the Advancement of Structured Information Standards). Para entender a importância, por exemplo, o W3C publica as especificações do HTML (Hypertext Markup Language) para garantir que todos os navegadores web possam ler os documentos HTML que se encontram na Web. Sem esta padronização, haveria risco de que sites web começassem a oferecer conteúdos que somente certos clientes poderiam entender, ou seja, a Web seria um fracasso. O aspecto mais crucial dos padrões é que sejam abertos, ou seja, um padrão que não pertença a nenhuma companhia ou organização que possa cobrar ou restringir o seu uso. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 8 4 Softwares importantes para a SOA A Rede Mundial de Computadores (Web) realmente deslanchou em 1994 e se tornou um veículo onipresente para a prestação de serviços no mundo. Quando algumas empresas da indústria química e aço usaram serviços na Web para estabelecer mercados online para melhorar a eficiência de gestão da cadeia de fornecedores, estranhamente, o software que executava estes serviços na Web ficou conhecido como software de Web services. 4.1 Do SGML ao HTML e XML O Extensible Markup Language (XML), assim com o HTML, foi criado pela W3C para gerar linguagens de marcação para algumas necessidades específicas. Um Markup language é um conjunto de instruções que você adiciona a uma coleção de palavras, figuras, tabelas e outras coisas para definir precisamente como esta coleção deve ser exibida em uma folha de papel, em uma tela de computador ou onde quiser exibi-la. O extensible quer dizer extensível, no sentido de poder estender capacidades, possibilidades e interoperabilidades. O XML e o HTML foram derivados do popular Standard Generalized Markup Language (SGML), que já existia desde o final dos anos 1960, mas não era adequado para uso na internet. Portanto, o HTML foi criado em 1986 e depois o XML foi criado em 1998, pois surgiu a necessidade de uma linguagem de marcação padrão, já que a Netscape e a Microsoft estavam em disputa intensa com suas versões de HTML. Outro motivador para a criação do XML é que não era possível prever todas as diferentes tags (linguagem de marcação) que poderiam ser necessárias para marcar os novos tipos de conteúdo. Era necessária uma linguagem que fosse extensível, que pudesse ser aumentada para suportar qualquer coisa nova que pudesse acontecer. O quadro 1 exemplifica um XML: Quadro 1 – Exemplo de como funciona um XML <Mensagem> <Para> Você, caro aluno </Para> <de> Professores do SENAC </De> <Título> Dica útil </Título> <Mensagem_texto> Vale lembrar que tags XML podem seru sadas para definir itens de dados. E você pode inventar todasas que precisa. As pessoas dizem que XML é extensível. E elas não estão erradas.<Mensagem_texto> </Mensagem> Fonte: Adaptada de Hurwitz et al. (2009, p.120).Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 9 Além de entender o poder de XML, é importante observar que ele trabalha junto com outros padrões importantes para realizar a comunicação na Web e também com uma variedade de padrões Web services. A seguir, no Quadro 2, são listados alguns destes principais padrões: Quadro 2 – Padrões para realização da comunicação WEB Padrão SOA O que significa O que é & para que é usado HTTP Hyper Text Transfer Protocol Padrão de endereço de páginas Web. Além de definir um endereço, HTTP também pode identificar um Web service. Ex.: o serviço de alertas que o Google oferece. XML eXtensible Markup Language Linguagem de definição que pode acompanhar informações. Ela diz a um programa de computador o que são realmente estas informações. SOAP Simple Object Access Protocol (simples protocolo de acesso ao objeto) Padrão que usa XML para descrever mensagens enviadas de um programa para outro. Um programa usa SOAP para solicitar um serviço de outro programa e, então, passar a ele dados relacionados. WSDL Web Services Description Language (linguagem de descrição de Web services) Padrão baseado em XML. Programadores usam WSDL para criar um documento XML, que descreve um Web service e como acessá-lo. UDDI Universal Description, Discovery and Integration (descrição, descoberta e integração geral) Framework para fazer o que sugere: descrever, descobrir e integrar serviços de negócio através da internet. O framework UDDI usa SOAP para se comunicar com programas que o acessam. REST REpresentational State Transfer (transferência de estado representacional) Interface simples para transferir dados através de HTTP sem as complicações adicionadas de uma camada de mensagem como SOAP ou o uso de rastreamento de sessão através de cookies HTTP. Pode ser usada para criar uma arquitetura. Fonte: Hurwitz et al. (2009, p.120-121). Este conjunto de padrões pode ser descrito, de forma simplificada, através da quadro 3: Quadro 3 – Simplificando a tabela de padrões para comunicação WEB √ HTTP – endereço √ XML – decodifica mensagens √ SOAP – escreve mensagens √ WSDL – descreve interfaces √ UDDI – diretório para encontrar serviços, como diretório de telefone √ REST – maneira simples de transferir dados pela Web e pode ser usado para criar arquiteturas sem estado Fonte: Hurwitz et al. (2009, p.120-121). Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 10 A versatilidade do XML é o que o faz diferente das tecnologias de componentes das gerações anteriores. Como o XML permite separar a estrutura gramatical (sintaxe) do significado gramatical (semântica) e separar o “como é processado e entendido por cada serviço” do ambiente onde ele existe, é possível definir objetos como serviços que se comunicam com outros serviços usando a gramática definida por XML, e cada serviço traduz e analisa a mensagem de acordo com sua implementação local e o seu ambiente. Para conhecer mais sobre XML e definições como XML Schema, acesse IBM – Introduction to XML. Para saber mais, acesso o link disponível na Midiateca da aula. 4.2 Web services O Web service é uma interface de software que descreve uma coleção de operações que podem ser acessados pela rede através de mensagens XML. Ele utiliza protocolos baseados na linguagem XML que descreve uma operação para executar ou trocar dados com outro Web service. Uma determinada aplicação Web service em uma arquitetura orientada a serviço poderia ser um grupo de Web services interagindo entre si (IBM, 2015). O XML descreve todo e qualquer dado de maneira realmente independente de plataforma para realizar o intercâmbio entre os sistemas. Com o fato do Web service usar o XML, se tornou possível a criação de aplicações de baixo acoplamento ou fracamente acoplado e, também, por funcionar em um nível mais abstrato, permite manipular dados de forma dinâmica e sob demanda. Por essa razão, os Web services estão ajudando a preencher a lacuna entre os empresários e tecnólogos de uma organização, facilitando o entendimento e alinhamento entre eles. Agora os executivos de negócio podem descrever os eventos e as atividades que desejam aos tecnólogos e estes conseguem associá-los aos serviços adequados. As interfaces definidas universalmente e as tarefas bem desenhadas tornam realidade a reutilização das tarefas e dos aplicativos que elas representam, trazendo assim um melhor retorno sobre o investimento em software, pois é possível produzir mais com os mesmos recursos. Inclusive, as áreas de negócio podem considerar o uso de um aplicativo existente dentro de uma nova oferta ou como um novo produto adicionando benefícios, potencializando, assim, o aumento de transações comerciais entre os parceiros de negócio. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 11 Considerações finais A arquitetura orientada a serviços foi estruturada sobre as melhores práticas que utilizam tecnologias, assim como modelos de desenvolvimento para tornar realidade a construção de serviços interoperáveis que apoiam o atingimento dos objetivos de negócio e de TI. Nesta aula descrevemos as principais tecnologias e recursos de TI que fundamentam a implementação, ou seja, viabilizam os princípios da orientação a serviços. E como vimos, eles são chave para alcançar a tão desejada interoperabilidade entre os serviços, sistemas e plataformas. As tecnologias passadas, as limitações dos softwares, os problemas enfrentados com a falta de controle ou governança e a evolução dinâmica do negócio, tudo isso ajudou a motivar a criação de novos recursos e melhores para que pudéssemos chegar até aqui. Figura 5 – Evolução tecnológica até chegar na Arquitetura Orientada a Serviço Portanto, a arquitetura orientada a serviço abraçou todas essas tecnologias que surgiram para facilitar a implementação das características dos princípios de design da orientação a serviços, da computação distribuída e dos padrões abertos e universais. Apenas para lembrar, a seguir os princípios de design da orientação a serviços: Figura 6 - Princípios de design da orientação a serviços Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 12 E um aspecto-chave mais abrangente e que está relacionado com todos esses anteriores: a interoperabilidade intrínseca. Referências HURWITZ, Judith et al. Arquitetura Orientada a Serviços: SOA para Leigos. Rio de Janeiro: Alta Books, 2009. __________; BLOOR, Robin; KAUFMAN, Marcia; HALPER, Dra. Fern. Arquitetura Orientada a Serviços – SOA para Leigos. Rio de Janeiro: Alta Books, 2009. IBM DEVELOPERWORKS. Technical topics: New to SOA and web services. Disponível em: <http:// www.ibm.com/developerworks/webservices/newto/service.html>. Acesso em: 2 jul. 2015. PULIER, Eric; TAYLOR, Hugh. Compreendendo SOA Corporativa. Rio de Janeiro: Ciência Moderna, 2008. Arquitetura Orientada a Serviço Aula 04 SOA sob a ótica de negócio Objetivos Específicos • Abordar os principais componentes da arquitetura que permitem um maior controle sobre os serviços de TI. Temas Introdução 1 Os desafios que os componentes SOA ajudam a resolver 2 Barramento de serviço corporativo 3 Registro e repositório SOA 4 Gerenciador de orquestração de processos de negócio 5 Service broker 6 Gerenciador de serviço SOA Considerações finais Referências Mikiko Ishida Professor Autor Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 2 Introdução Vamos conhecer os principais componentes da arquitetura orientada a serviço (SOA) que permitem torná-la realidade, seguindo os princípios da orientação a serviço, para trazer os benefícios de negócio esperados pelas empresas. Cada um desses componentes de SOA (representados na Figura 1) desempenha o seu papel, funciona de forma independente, mas também interage um com o outro. Quanto mais sintonizados esses componentes estiverementre si, melhor será o nível de serviço que a arquitetura orientada a serviço fornecerá ao negócio. Figura 1 – Componentes fundamentais da Arquitetura Orientada a Serviço (SOA) Fonte: Adaptada de Hurwitz et al. (2009, p. 72). O ESB1 (barramento de serviço corporativo): ajuda a enviar e receber as mensagens entre os componentes de uma implementação SOA. • O registro e repositório SOA: contém informações de referência importantes para a localização dos componentes de SOA. • O gerenciador de orquestração de processos de negócio: provê a tecnologia para conectar pessoas com pessoas, pessoas com processos e processos com processos. • O service broker ou o mediador de serviço: conecta serviços com serviços, viabilizando o fluxo de processo de negócio. • O papel do gerenciador de serviço SOA é garantir que o ambiente SOA e a tecnologia que o suporta funcionem consistentemente e de forma previsível. O objetivo é criar 1 ESB vem do termo em inglês Enterprise Service Bus, ou seja, barramento de serviço corporativo ou apenas barramento de serviço. É onde acontecem as comunicações entre os serviços da arquitetura orientada a serviço. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 3 um ambiente onde todos os serviços que trabalham juntos possam ser conectados a componentes de tecnologia ainda não relacionados, como se tivessem sido projetados para trabalhar juntos e, assim, possam melhorar o fluxo do processo de negócio. 1 Os desafios que os componentes SOA ajudam a resolver 1.1 Separação de interesses O mundo de SOA pode ser dividido em camada de serviços de negócio e camada de plumbing (termo em inglês que lembra um encanamento, que leva o conteúdo para vários pontos da rede). A primeira contém a lógica de negócio e a segunda lida com os recursos da computação. Um dos maiores desafios do desenvolvimento de aplicações de negócio é conseguir manter a lógica de negócio (ex.: incluir uma linha de pedido; atualizar o saldo em estoque; agendar a entrega via transportadora etc.) separada da lógica de plumbing (ex.: abrir conexão com o banco de dados ABC; verificar se a impressora está conectada etc.). Figura 2 – Exemplo de separação de interesses (camada de negócio da camada de” plumbing”) Fonte: Adaptada de Hurwitz et al. (2009, p. 51). Utilizando ferramentas de software apropriadas e disciplina do desenvolvedor para garantir esta separação, é possível manter a lógica de negócio separada da tecnologia que a faz acontecer. A separação de interesses é frequentemente ignorada por requerer mais tempo e esforço, porém, no futuro, os custos desta decisão serão altos. Criar uma arquitetura reutilizável exige disciplina e os gestores de TI precisam ser instruídos para que estejam cientes. O esforço inicial e exigência da disciplina são pagos ao longo do tempo, com dividendos. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 4 1.2 Reutilização do sistema legado como serviço Com o SOA, muitas aplicações de negócio existentes poderão ser tratadas como serviço, ou parte delas pode ser extraída e colocada em um novo serviço. Para incluí-las na arquitetura SOA, algumas alterações ou a adição de adaptadores ou interfaces poderão ser necessárias. A criação de um adaptador pode não ser simples, mas sua função é clara. Permite conectar uma aplicação de negócio existente (legado) à arquitetura SOA. A arquitetura SOA utiliza padrões específicos e, de acordo com a indústria, é possível criar essas interfaces que permitam a vários componentes se comunicarem como componentes SOA. Após criar todos os elementos exigidos pela arquitetura SOA, você pode incluir uma aplicação existente ou parte dela, dentro do framework SOA. Os fornecedores de pacotes de software têm oferecido adaptadores para conectar o pacote à sua arquitetura SOA. Figura 3 – Cenário com acréscimo de aplicação existente na composição de serviços do exemplo anterior Fonte: Adaptada de Hurwitz et al. (2009, p. 53). 1.3 Aplicação existente tratada como caixa-preta A SOA também é definida como uma arquitetura de componente caixa-preta, pois esconde a complexidade deliberadamente sempre que possível. A caixa-preta permite a reutilização de aplicações de negócios existentes, adicionando um adaptador simples nelas sem importar com a forma como foram construídas. Apesar de dividir a arquitetura em camadas de negócio e de plumbing, muitos componentes da camada de negócio vêm de aplicações existentes que foram criadas de formas diferentes e incluem tudo como lógica de aplicação. Muitas vezes são aplicações antigas e sem fonte, mas funcionam e são críticas para o negócio da empresa ainda hoje. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 5 Portanto, são chamadas de caixa-preta, pois não é possível entender como foram construídas e não são acessíveis. Mesmo que não saibamos como foram desenvolvidas, sabemos como utilizá-las. Com SOA é possível tratar essas caixas-pretas como componentes de serviço, adicionando adaptadores para que possam interagir com os novos componentes. 1.4 Coordenação de componentes Ao colocar as aplicações antigas e “bagunçadas” em caixas-pretas, não significa que tudo vai correr bem. É necessário saber como essas caixas-pretas serão unidas para garantir o serviço de ponta a ponta. São muitas variáveis e o plumbing de cada caixa-preta pode ser totalmente diferente. Se um deles não funcionar, como saber? Um gerenciador de serviços SOA é necessário para coordenar o processamento de todos estes componentes. O gerenciador de serviços SOA é um ambiente de gerenciamento virtualizado que age como um guarda de trânsito que tenta monitorar o tráfego, com a intenção de garantir que acidentes não ocorram. 2 Barramento de serviço corporativo A arquitetura orientada a serviço é um paradigma de construção e integração. Todos os diferentes pedaços de software que participam de SOA se comunicam enviando e recebendo muitas mensagens. Essas mensagens precisam ser entregues com rapidez e seu recebimento deve ser garantido, pois são críticas para a entrega de serviço de negócio de ponta a ponta. Sem isso, não há serviço. Portanto, o transporte de mensagens entre os componentes de software na arquitetura orientada a serviço é realizado no Barramento de Serviço Corporativo (ESB). O barramento de serviço corporativo é tão importante para a SOA que muita gente pensa que sem ele não é possível ter SOA ou acham que o fato de ter um ESB implementado significa que já conquistaram SOA. Nenhuma dessas alternativas é verdade. A utilização deste barramento não é obrigatório; porém, a comunicação entre os serviços é necessária e, por isso, muitas empresas optaram por utilizar o ESB para realizar a integração universal dos serviços. Podemos imaginar o ESB como uma camada especial que roda sobre a rede de comunicação e oferece um serviço de mensagens garantido entre os componentes SOA. De fato, o barramento de serviço é um middleware2 que possibilita a comunicação entre vários elementos de uma solução orientada a serviços. Ele viabiliza a arquitetura orientada a serviço conectando um ambiente heterogêneo com diversas tecnologias e protocolos de comunicação, permitindo inclusive a criação de serviços a partir de aplicações legadas, através de mediações. 2 Middleware é uma camada de software que permite conectar diferentes aplicações de software em sistemas distribuídos. Senac São Paulo - Todos os Direitos Reservados Arquitetura Orientada a Serviço 6 Nos diagramas de arquitetura, geralmente o ESB é representado com um cano separado onde os componentes de software se conectam e por onde as informações e instruções fluem. Na Figura 4 temos esta representação. Na realidade, o ESB é uma coleção de componentes de software que gerencia mensagens de um componente de software para outro. Ao se conectar no ESB, um componente de software passa uma mensagem em um formato específico
Compartilhar