UFG - Instituto de Informática

Transcrição

1 UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 14 SOA e ESB

2 Service-Oriented Architecture Service-Oriented Architecture (SOA) ou arquitetura orientada a serviços: É um estilo de arquitetura de software cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços.

3 Service-Oriented Architecture Frequentemente estes serviços são conectados através de um barramento de serviços (Enterprise Service Bus ESB) O ESB disponibiliza interfaces, ou contratos, acessíveis através de web services ou outra forma de comunicação entre aplicações.

4 Service-Oriented Architecture A arquitetura SOA é baseada nos princípios da computação distribuída e utiliza o paradigma Requisição/Resposta (Request/Reply) para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.

5 Service-Oriented Architecture SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas. - Gartner Group

6 SOA As implementações SOA dependem de uma rede de serviços de software. Serviços incluem baixo acoplamento de unidades e de funcionalidade.

7 SOA Cada serviço implementa uma ação. Por exemplo: preencher um requerimento on-line para uma conta, visualizar um banco on-line de instrução, ou colocar uma reserva on-line ou para bilhete de avião.

8 SOA Desenvolvedor SOA associa objetos individuais usando orquestração. No processo de orquestração o desenvolvedor associa funcionalidade de software (serviços) em um arranjo não-hierárquica osando uma ferramenta de software que contém uma lista completa de todos os serviços disponíveis, suas características e os meios para criar uma aplicação utilizando essas fontes.

9 SOA SOA depende dos dados e serviços que são descritos por metadados que devem satisfazer os seguintes critérios: 1. Os metadados devem vir de uma forma que os sistemas de software pode usar para configurar dinamicamente a descoberta e a incorporação de serviços definidos, e também para manter a coerência e integridade. 2. Os metadados devem vir de uma forma que os designers de sistema capaz de compreender e gerir com um gasto razoável de custo e esforço.

10 Requisitos para SOA A fim de utilizar eficientemente uma SOA deve: Prover interoperabilidade entre diferentes sistemas e linguagens de programação. Estabelecer e manter o fluxo de dados para um sistema de banco de dados federado. Isto permite que novas funcionalidades desenvolvidas para fazer referência a um formato de negócios comuns para cada elemento de dados.

11 SOA - Princípios Os seguintes princípios orientadores definem as regras básicas para o desenvolvimento, uso, manutenção e do SOA: reutilização, granularidade, modularidade, agregabilidade componentização, e interoperabilidade. padrões de conformidade (comuns e específicas da indústria). serviços de identificação e categorização, fornecimento e entrega, e monitoramento e rastreamento.

12 SOA - Princípios A primeira pesquisa publicada sobre orientação a serviços a partir de uma perspectiva da indústria foi fornecida por Thomas Erl da SOA Systems Inc., que definiu oito princípios específicos da orientação a serviços comuns a todas as principais plataformas SOA.

13 SOA - Princípios Contrato de serviço padronizado Serviços aderem a um acordo de comunicações, como definido coletivamente por um ou mais serviços de descrição de documentos. Fraco acoplamento de serviços Serviços mantem um relacionamento que minimiza as dependências e só exige que eles mantenham uma consciência de si. Abstração de serviços além das descrições no contrato de serviço, os serviços devem esconder a lógica do mundo exterior.

14 SOA - Princípios Reutilização de serviço A lógica é dividida em serviços com a intenção de promover a reutilização. Autonomia de Serviço Os serviços têm controle sobre a lógica que encapsulam. Granularidade serviço O projeto deve considerar fornecer um escopo ótimo e um nível granular da funcionalidade de negócios em uma operação de serviço.

15 SOA - Princípios Serviços sem estado Serviços minimizam o consumo de recursos, adiando a gestão de informações de estado, quando necessário Descoberta de Serviços Os serviços são complementados com meta comunicação de dados pelo qual eles podem ser efetivamente descobertos e interpretados. Componibilidade de Serviços Serviços são participantes de composição efetiva, independentemente do tamanho e complexidade da composição.

16 SOA - Princípios Alguns autores também incluem os seguintes princípios: Otimização de serviços Tudo o mais igual, serviços de alta qualidade são geralmente preferível a baixa qualidade queridos. Relevância de serviços Funcionalidade é apresentado em uma granularidade reconhecido pelo usuário como um serviço significativo. Encapsulamento de serviços Muitos serviços são consolidadas para o uso sob a SOA. Muitas vezes, tais serviços não foram planejados para estar sob SOA.

17 SOA - Princípios Transparência de Serviço de Localização Refere-se à capacidade de um consumidor de serviço para invocar um serviço, independentemente de sua localização real na rede.

18 SOA com abordagem em WebServices Serviços Web podem implementar uma arquitetura orientada a serviços. Serviços Web fazem blocos funcionais de construção acessíveis através de protocolos de Internet padrão independente de plataformas e linguagens de programação. Estes serviços podem representar tanto novas aplicações quanto apenas invólucros em torno dos sistemas legados existentes para torná-los em rede ativada.

19 SOA com abordagem em WebServices Cada bloco de construção SOA pode desempenhar um ou ambos os papéis: Service provider (Provedor de Serviço) Service consumer (Consumidor de Serviço)

20 Provedor de Serviços O provedor de serviços cria um serviço Web e, eventualmente, publica sua interface e acesso a informação para o registro de serviços. Cada fornecedor deve decidir quais os serviços irá expor, como fazer trade-offs entre a segurança e a facilidade de acesso, como preço dos serviços, ou (se nenhuma taxa extra), como e se a explorá-los para outro valor.

21 Provedor de Serviços O provedor também tem que decidir em qual categoria os serviços devem ser listados em um dado service broker (corretor de serviço) e que tipo de acordos com parceiros comerciais são obrigados a usar o serviço. Ele registra que os serviços estão disponíveis dentro dele, e as listas de todos os beneficiários potenciais do serviço. O implementador do corretor, então, decide o escopo do corretor.

22 SOA - Tecnologia O termo "Service-Oriented Architecture" (SOA) ou Arquitetura Orientada a Serviços expressa um conceito no qual aplicativos ou rotinas são disponibilizadas como serviços em uma rede de computadores (Internet ou Intranets) de forma independente e se comunicando através de padrões abertos.

23 SOA - Tecnologia A maior parte das implementações de SOA se utilizam de Web Services (SOAP, REST e WSDL). Entretanto, uma implementação de SOA pode se utilizar de qualquer tecnologia padronizada baseada em web.

24 SOA - Conceitos Acoplamento É o nível de interdependência entre os módulos de um sistema. Por outro lado, um módulo é considerado coeso quando possui uma atividade bem definida. Diferentemente do que as pessoas pensam, SOA não se trata de uma simples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas de mercado, que se faz cada vez mais exigente em qualidade e agilidade.

25 SOA - Conceitos Serviço Um serviço, do ponto de vista da arquitetura SOA, é uma função de um sistema computacional que é disponibilizado para outro sistema. Um serviço deve funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços compostos (composite services), e deve possuir uma interface bem definida. Normalmente, a comunicação entre o sistema cliente e aquele que disponibiliza o serviço é realizada através de web services.

26 SOA - Conceitos Orquestração Processo de sequenciar serviços e prover uma lógica adicional para processar dados. Não inclui uma representação de dados.

27 SOA - Conceitos Sem Estado Não depende de nenhuma condição pré-existente. Os serviços não devem depender de condições de outros serviços. Eles recebem todas as informações necessárias para prover uma resposta consistente. O objetivo de buscar a característica stateless dos serviços é possibilitar que o consumidor do serviço possa sequenciá-lo, ou seja, orquestrá-los em vários fluxos (algumas vezes chamados de pipelines) para executar a lógica de uma aplicação.

28 SOA - Conceitos Provedor O recurso que executa o serviço em resposta a uma requisição de um consumidor.

29 SOA - Conceitos Consumidor É quem consome ou pede o resultado de um serviço fornecido por um provedor.

30 SOA - Conceitos Descoberta SOA se baseia na capacidade de identificar serviços e suas características. Conseqüentemente, esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio.

31 SOA - Conceitos Binding - Ligação A relação entre os serviços do provedor e do consumidor deve ser idealmente dinâmica; Ela é estabelecida em tempo de execução através de um mecanismo de binding.

32 SOA - Conceitos Processos A Arquitetura Orientada a Serviços pode ser bem representada a partir do seguinte processo, chamado de paradigma find-bind-execute o que significa aproximadamente paradigma de procuraliga-executa.

33 SOA - Conceitos

34 Orquestração e Coreografia Orquestração e Coreografia são dois termos comumente utilizados para composição de processos de negócio através de Web Services, sendo muitas vezes usados um no lugar do outro, o que causa problemas.

35 Orquestração e Coreografia Processo Mestre processo que coordena a composição de processos e controla sua execução dentro de uma orquestração. Processo Participante processo que participa de uma composição de processos.

36 Orquestração e Coreografia Orquestração composição de processos de negócio (através de Web Services) onde existe a figura de um processo central (processo mestre) que controla e coordena os demais processos. Neste tipo de composição, cada processo participante não tem conhecimento de que faz parte de uma composição de processos, com exceção do processo mestre.

37 Orquestração e Coreografia Coreografia composição de processos de negócio (através de Web Services) onde não existe a figura de um processo mestre que controla e coordena os demais processos. Neste tipo de composição, cada processo envolvido tem o conhecimento de que faz parte de uma composição de processos e que precisa interagir com outros processos de maneira ordenada para que a composição resultante tenha sucesso.

38 Orquestração e Coreografia Somente o processo mestre detém a inteligência sobre o processo completo, e a execução é então centralizada. Devido a essa centralização, orquestrações ocorrem normalmente dentro de uma mesma corporação, uma vez que dentro dessa corporação é simples decidir qual processo será o processo-mestre.

39 Orquestração e Coreografia Cada processo participante sabe exatamente quando atuar, com quais outros processos participantes interagir, quais operações deve executar, quais mensagens deve trocar e até mesmo o momento adequado de troca de mensagens. Devido à esta descentralização, coreografia de processos costuma ser utilizada entre processos ou Web Services de corporações distintas.

40 Enterprise Service Bus O Enterprise Service Bus se refere à arquitetura de construção de software tipicamente implementado em tecnologias encontradas na categoria de produtos de infraestrutura de middleware. Normalmente baseado no reconhecimento de padrões, que fornecem uma base de serviços para arquiteturas mais complexas via um driver de evento e padrões baseados em mensagens (BUS).

41 EAI EAI (do inglês Enterprise Application Integration) é uma referência aos meios computacionais e aos princípios de arquitetura de sistemas utilizados no processo de Integração de Aplicações Corporativas. Os procedimentos e ferramentas de EAI viabilizam a interação entre sistemas corporativos hetereogêneos por meio da utlização de serviços.

42 EAI Os pontos básicos de uma arquitetura de EAI são: Integração de aplicações, sistemas de informação e processos de negócio de uma empresa. Integração com aplicações internas e externas da empresa que servem de suporte ao processo de negócio da mesma, como por exemplo processo financeiro, recursos humanos, dentre outros. Conjunto de ferramentas de análise e monitoração de processos em tempo real.

43 EAI Os componentes presentes em um arquitetura de integração de sistemas são: Sistemas - Refere-se aos Sistemas que trocarão informações entre si. (Ex. Software de CRM (SIEBEL) trocando informações com software de faturamento (SAP) Dados - Conjunto de dados (layouts de arquivos) que serão trafegados pela arquitetura durante a troca de dados entre os sistemas.(ex. XML ou texto)

44 EAI Interface - Forma de enviar receber dados entre os sistemas. (Ex. Web services, adaptadores) Comunicação - Tipo de comunicação a ser utilizada durante a troca de informações entre os sistemas. (Ex. síncrona ou assíncrona).

45 EAI Os estilos de integração entre sistemas utilizando-se do EAI são: File Transfer - Integração entre aplicativos através da troca de arquivos em formato de texto definido. Shared Database - Integração entre aplicativos através da troca de dados entre bases de dados ou tabelas. Remote Procedure Invocation - Integração entre aplicativos através da chamada a programas remotos os quais são responsáveis pela extração, envio/recebimento e persistência dos dados no sistema.

46 EAI Messaging - Integração entre aplicativos de um middleware orientado a mensagem (MOM) o qual e responsável pela entrega dos dados aos sistema integrados.

47 Melhores Práticas Buscar uma padronização na forma de integração com os sistemas legados facilita manutenções futuras. A definição de um padrão na forma de trabalho das interfaces pode promover o reuso das mesmas. Quanto menos camadas existirem entre à aplicação legada e a plataforma de integração (EAI) menores são as chances de ocorrerem erros durante a troca de dados entre elas. A redução no número de camadas por onde os dados tem de passar até chegar a seu destino, promove também uma melhor performance durante o processo de troca de dados entre aplicações.

48 Soluções de EAI Intersystems Ensemble TIBCO - Webmethods - Webpshere MQSeries/Broker - IBM Vitria - BizTalk - Microsoft SeeBeyond - SunMicrosystem BEA Weblogic Integration - BEA

49 Soluções de EAI SAP Exchange Infrastructure (XI) ou Process Integration (PI) - SAP Datasul EAI - Datasul - IRIS - Databridge - IntraFlow BPMS IntraFlow - Guaraná SDK -

50 BPEL Business Process Execution Language (BPEL), abreviação de Web Services Business Process Execution Language (WS-BPEL) É uma linguagem executável padrão oásis para a especificação de ações dentro de processos de negócios com serviços web. Processos em Business Process Execution Language exportam e importam as informações usando interfaces de serviço web exclusivamente.

51 BPEL Interações de serviços Web pode ser descrito de duas formas: processos executáveis de negócio e processos de negócio abstrato. Negócio executável processos comportamento do modelo real de um participante de uma interação de negócios. Processos de negócio abstratos são processos parcialmente especificado que não se destinam a ser executado.

52 BPEL Um processo abstrato pode esconder alguns dos necessários concreto detalhes operacionais. Processos abstratos têm um papel descritivo, com mais de um caso de uso possíveis, incluindo o comportamento observável e / ou modelo de processo. WS-BPEL é feito para ser usado para modelar o comportamento de ambos os executáveis e processos abstratos.

53 BPEL WS-BPEL fornece uma linguagem para a especificação de executáveis e processos de negócio abstrato. Ao fazer isso, ele estende o modelo de interação Web Services e permite que ele suporte as transações comerciais. WS-BPEL define um modelo de integração interoperável que deve facilitar a expansão da integração de processos automatizados dentro e entre empresas.

54 Objetivos 1 - Definir processos de negócio que interagem com entidades externas através de serviços web operações definidas usando WSDL 1.1, e que se manifestam como serviços Web definidos com o WSDL 1.1. As interações são "abstratas" no sentido de que a dependência é sobre as definições porttype, e não em definições de porta.

55 Objetivos 2 - Definir processos de negócios usando uma linguagem baseada em XML. Não definem uma representação gráfica de processos ou fornecer qualquer metodologia de projeto particular para processos.

56 Objetivos 3 - Definir um conjunto de conceitos Web orquestração de serviços que se destinam a ser usados por ambas as visões externas (abstrato) e internas (executável) de um processo de negócio.

57 Objetivos 4 - Fornecer tanto hierárquica e regimes gráfico de como o controle e permitir a sua utilização para ser misturado de forma tão integrada quanto possível. Isso deve reduzir a fragmentação do espaço de modelagem de processos.

58 Objetivos 5 - Fornecer funções de manipulação de dados para a simples manipulação dos dados necessários para definir os dados do processo e de controle de fluxo.

59 Objetivos 6 - Apoiar um mecanismo de identificação para instâncias processo que permite a definição de identificadores exemplo no nível de mensagem de aplicativos. Identificadores de instância deve ser definida pelos parceiros e pode mudar.

60 Objetivos 7 - Apoiar a criação implícita e rescisão de instâncias de processos como o mecanismo básico do ciclo de vida. Operações avançadas do ciclo de vida, tais como "suspender" e "resume" podem ser adicionados em versões futuras para a gestão do ciclo de vida melhorada.

61 Objetivos 8 - Definir um modelo de transação de longa duração que é baseada em técnicas comprovadas como ações de compensação e de escopo para apoiar a recuperação de falhas de peças de processos de negócio de longo prazo.

62 Objetivos 9 - Usar os Serviços Web como o modelo para a decomposição do processo e montagem Criação de padrões de serviços Web (aprovado e proposto), tanto quanto possível de uma forma de composição e modular. Observação: BPEL é uma orquestração de linguagem, não uma coreografia linguagem.

63 Enterprise Service Bus Um ESB geralmente fornece uma abstração de camadas na implementação de um sistema empresarial de mensagens, que permita integração da arquitetura para explorar o valor das mensagens sem escrever código. Contrariando a clássica integração de aplicações comerciais (EAI). A base de um enterprise service bus é construida da quebra de funções básicas em partes, que são distribuidas onde for preciso.

64 Enterprise Service Bus ESB não implementa uma arquitetura orientada a serviço (SOA), mas fornece as características para que possa ser implementado. ESB não necessariamente precisa ser implementado usando web-services. ESB devem ser baseados em padrões flexíveis, suportando vários meios de transportes.

65 Enterprise Service Bus Baseado no EAI melhor que padrões SOA, ele tenta remover o acoplamento entre o serviço chamado e o meio de transporte. A maioria dos fornecedores de ESB constroem agora ESBs para incorporar princípios de SOA e para aumentar suas vendas, por exemplo Business Process Execution Language(BPEL).

66 Enterprise Service Bus

67 Enterprise Service Bus A palavra bus é a referência para o meio físico que carrega bits entre dispositivos em um computador. O ESB serve a uma função análoga a alto nível de abstração. Em uma arquitetura empresarial fazendo uso de um ESB, uma aplicação irá comunicar via barramento, que atua como um message broker entre aplicações.

68 Enterprise Service Bus A principal vantagem de com uma aproximação é a redução de conexões ponto a ponto necessárias para permitir a comunicação entre aplicações. Isto por sua vez afeta diretamente na simplificação das mudanças de sistema. Por reduzir o número de conexões ponto a ponto para uma aplicação específica, o processo de adaptar um sistema às mudanças em um de seus componentes torna-se mais fácil.