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
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.
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.
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.
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
SOA
As implementações SOA dependem de uma
rede de serviços de software.
Serviços incluem baixo acoplamento de
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.
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.
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.
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.
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.
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.
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
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.
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,
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 - 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.
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.
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)
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.
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.
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.
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.
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
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.
SOA - Conceitos
Orquestração
Processo de sequenciar serviços e prover uma
lógica adicional para processar dados.
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.
SOA - Conceitos
Provedor
O recurso que executa o serviço em resposta a
SOA - Conceitos
Consumidor
É quem consome ou pede o resultado de um
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.
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
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 “procura-liga-executa”.
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.
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
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.
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.
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.
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.
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 infra-estrutura 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).
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.
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
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)
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).
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
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.
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
Soluções de EAI
Intersystems Ensemble
http://www.intersystems.com.br/isc/ensemble/index.csp
TIBCO - http://www.tibco.com
Webmethods - http://www.webmethods.com
Webpshere MQSeries/Broker - IBM
Vitria - http://www.vitria.com/BusinessWare/
BizTalk - Microsoft
SeeBeyond - SunMicrosystem
Soluções de EAI
SAP Exchange Infrastructure (XI) ou Process Integration (PI) -
SAP
Datasul EAI - Datasul - www.datasul.com.br
IRIS - Databridge - http://www.databridge.com.br
IntraFlow BPMS 2.0 - IntraFlow - http://www.intraflow.com.br
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Objetivos
9 - Usar os Serviços Web como o modelo para a decomposição do processo e montagem.
10 - 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
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.
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
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).
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.
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
