Visão que incorpora na arquitectura tecnológica o suporte aos conceitos SOA Explicitar o Bus de Serviços Os workflows e as orquestrações de processos 3/2/2005 José Alves Marques 1 Domínios da Arquitectura Arquitectura de Serviços de Integração Define os serviços que suportam o negócio e que devem ser de grão grosso, fracamente interligados, reutilizáveis Arquitectura de Informação de Integração Mantém uma visão comum dos dados da organização Metadata que permite correlacionar e manter a integridade dos dados entre aplicações Arquitectura de Integração de Processos A arquitectura de processos descreve os processos que atravessam as fronteiras dos sistemas de negócio Arquitectura Técnica de Integração Define as tecnologias subjacentes à integração São os elementos de base que permitem o estabelecimento de canais de interacção Ex.: Messaging, interfaces de aplicações, web services 3/2/2005 José Alves Marques 2
Domínios da Arquitectura de Integração 3/2/2005 José Alves Marques 3 Service Oriented Architecture (SOA) 3/2/2005 José Alves Marques 4
O que é o SOA: é certamente a curiosidade do momento 3/2/2005 José Alves Marques 5 O que é o SOA? Não existe uma definição formal! A seguinte definição está entre as mais consensuais: SOA é uma arquitectura centrada na noção de que os activos (assets) dos SI numa organização são descritos e expostos como Serviços. Estes Serviços podem ser compostos e orquestrados em Processos de Negócio, permitindo agilizar os mesmos, e lidar com a sua dinâmica. Como arquitectura o SOA não está obrigatoriamente ligada a nenhuma tecnologia. Contudo, na prática, o SOA está associado a uma série de novas tecnologias: WS, SOAP, BPEL4Ws, WSCI, UDDI, XML, HTTP,. 3/2/2005 José Alves Marques 6
O SOA é uma evolução As ideias do SOA e do Object-Oriented Analysis and Design são semelhantes, com uma clara mudança de granularidade Grady Booch numa entrevista recente disse "the fundamentals of engineering like good abstractions, good separation of concerns never go out of style", but he also pointed out that "there are real opportunities to raise the level of abstraction again." A experiência passada indica que o nível de abstracção tem de ser elevado ao nível dos conceitos de negócio da empresa, considerando a arquitectura de sistemas de informação da empresa como um todo e não em visões fragmentadas de aplicações 3/2/2005 José Alves Marques 7 SOA: Web Services (standards) Management Choreography - CDL4WS Orchestration - BPEL4WS Web Services são tecnologia Transactions WS-Reliability WS-Security Coordination UDDI WSDL Context Business Processes Quality of Service Discovery Description SOAP XML HTTP, JMS, SMTP Message Transport 3/2/2005 José Alves Marques 8
Service Oriented Architecture Cantores, instrumentistas, costureiros e cenógrafos 3/2/2005 José Alves Marques 9 Serviços Um serviço encapsula uma função de negócio reutilizável Os serviços são definidos explicitamente com interfaces independentes da implementação Os serviços são fracamente interligados e invocados através de protocolos de comunicação independentes da localização e da tecnologia de suporte 3/2/2005 José Alves Marques 10
Serviço é oferecido num único sítio Depois de uma função de negócio ter sido definida como um serviço Cada serviço e instanciado num único sítio e invocado remotamente nesse sítio por todas as aplicações que o usam (não existem réplicas com potenciais evoluções independentes) Não existe herança ou dependências fortes entre serviços Cada serviço é criado (build) uma vez mas pode ser instanciado (deployed) para todos os sistemas que dele necessitem. 3/2/2005 José Alves Marques 11 Serviço = Contracto (interface) + Implementação SOA define um conjunto de princípios de desenho de software Define a topologia de uma aplicação/sistema/solução em função da definição de um conjunto de interfaces ( contratos ), implementações das interfaces definidas e das mensagens (ou chamadas ) trocadas entre essas interfaces. Também poderia chamar-se IOA - Interface Oriented Architecture 3/2/2005 José Alves Marques 12
SOA é uma revolução Organizacional e uma evolução Técnica... baseada em componentes... baseada em serviços Modelo procedimental (orientado à invocação de funções) Produto mais rígido (build to last) Ciclos de desenvolvimento longos Favorece o desenvolvimento de aplicações isoladas e independentes ( nichos aplicacionais) Partes fortemente ligadas (tightly coupled) Modelo de comunicação orientada ao objecto Modelo colaborativo /event-driven (orientado às chamadas para fornecimento/consumo de serviços) Produto mais flexível (build to change) Desenvolvimento (e deployment) incremental Favorece o desenvolvimento de soluções integradas Partes fracamente ligadas (loosely coupled) Modelo de comunicação orientado a mensagens Foco 3/2/2005 na implementação ( como faz ) José Alves Marques Abstracção ( o que faz ) 14 SOA - Síntese Foco na funcionalidade e não na sua implementação Foco em o que faz? e não como faz Separação clara entre o fornecedor e o consumidor do serviço Foco na definição dos contractos Funcionais obrigações do fornecedor e do consumidor Não-funcional SLAs (Service Level Agreements) Capacidade de composição e agregação de serviços mais básicos no desenvolvimento de serviços mais complexos/completos 3/2/2005 José Alves Marques 15
Propriedades dos Serviços 3/2/2005 José Alves Marques 17 Propriedades (desejáveis) dos Serviços SOA Grão Largo Fracamente interligados Sem Ligação Descobertos e ligados dinamicamente Auto contidos e modulares Interfaces endereçáveis na rede Transparentes à localização Podem ser compostos ou orquestrados Induzem interoperação Permitem auto recuperação de faltas 3/2/2005 José Alves Marques 18
Granularidade Service Layer Component Layer Class Layer Service Oriented Design Component Oriented Design Object-Oriented Design 3/2/2005 José Alves Marques 19 Granularidade O SOA considera serviços de grão largo É importante que a definição de serviço encapsule a função suficientemente bem para que seja reutilizável Mas podemos facilmente encontrar múltiplos exemplos de funções de grau mais fino que são úteis na reutilização. A definição dos serviços e da respectiva granularidade é uma das questões difíceis É necessário um mecanismo de composição ou orquestração entre cada nível de granularidade. 3/2/2005 José Alves Marques 20
Orquestração ou Agregação 3/2/2005 José Alves Marques 21 Fracamente Interligado - Loosely Coupled Um serviço fracamente interligado quer dizer que se restringe o número de coisas que uma aplicação cliente necessita de saber acerca do serviço que invoca. Num serviço fortemente interligado qualquer modificação no cliente ou servidor obriga a mudar o código de ambos. Fracamente interligado não põe em causa que determinados serviços só possam ser invocado se as respectivas interacções respeitarem requisitos não funcionais como segurança, atomicidade, etc. 3/2/2005 José Alves Marques 22
Estilos de relacionamento dos serviços com os clientes Coupled Fortemente interligado Loosely Coupled Fracamente interligado Declarado - A interface especifica requisitos que só permitem a interacção se houver compatibilidade (a ideia é que seja automaticamente resolvido pela infra-estrutura de suporte. Esta noção leva aos Entreprise Bus com capacidade de inteligentemente efectuarem a adaptação) Negociated Se existirem comportamentos que ambos suportam, a infra-estrutura é capaz de negociar um que seja aceitável para cada interacção Transformed Se a infra-estrutura permitir a transformação para adaptar os requisitos do cliente e do servidor 3/2/2005 José Alves Marques 23 Serviços sem Ligação Um serviço sem ligação quer dizer que o cliente e o servidor não necessitam de manter estado entre invocações sucessivas A chave do SOA é definir comportamento o que deveria eliminar o problema Desenho de interfaces de serviço que não dependem de conhecimento partilhado implícito. O serviço pode lidar com um comportamento de negócio com estado ou sem estado, mas a sua interface ser sem ligação O uso de tecnologia que não implique a existência de handles para instancias executáveis. 3/2/2005 José Alves Marques 24
Síntese da abordagem serviços e orquestração 3/2/2005 José Alves Marques 25 Processo de Reparação de Automóveis - exemplo 3/2/2005 José Alves Marques 26
Visão OO das classe que poderiam implementar a aplicação 3/2/2005 José Alves Marques 27 Modelação do Processo de Negócio 3/2/2005 José Alves Marques 28
Visão do modelo de Serviços 3/2/2005 José Alves Marques 29