Service Oriented Architecture (SOA)

Transcrição

1 Service Oriented Architecture (SOA) 3/2/2005 José Alves Marques 1 Modelo dos Web Services Service Registry Find Publish Service Requestor Request Bind /Response Service Provider 3/2/2005 José Alves Marques 2

2 Arquitectura dos WEB services Um serviço de Directório para registo e pesquisa dos serviços UDDI Um protocolo de pedidoresposta para invocação do serviço SOAP Uma especificação da interface do serviço WSDL Páginas amarelas e directório Interacção Contratos 3/2/2005 José Alves Marques 3 SOA: Web Services (standards) Choreography - CDL4WS Orchestration - BPEL4WS Business Processes Management UDDI WSDL Transactions WS-Reliability WS-Security Coordination Web Services são tecnologia Context Quality of Service Discovery Description SOAP XML HTTP, JMS, SMTP Message Transport 3/2/2005 José Alves Marques 4

3 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 que é o SOA não está obrigatoriamente ligada a nenhuma tecnologia. Contudo, na prática, o SOA está associado a uma à tecnologia dos Web Services: WS, SOAP, BPEL, WSCI, UDDI, XML, HTTP,. 3/2/2005 José Alves Marques 6

4 Service Oriented Architecture 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 7 SOA: uma primeira visão Figura do CBDI Forum, SOA: Consideration for Agile Systems. MS Journal2 3/2/2005 José Alves Marques 8

5 Abstracções do SOA Operações: Transacção que representam uma unidade lógica de trabalho (LUWs). A execução de uma operação deverá tipicamente provocar que um ou mais dados persistentes sejam lidos, escritos ou modificados..as operações SOA são comparáveis com os métodos object-oriented (OO). Têm uma determinada interface com estrutura definida e retornam respostas estruturadas.. Tal como os métodos, a execução de uma operação pode provocar a invocação de operações adicionais Services: Representa um agrupamento lógico de operações. Business Processes: Uma actividade ou um conjunto de acções de longa duração executadas para um objectivo de negócio específico Um processo de negócio tipicamente compreende várias invocações a serviços 3/2/2005 José Alves Marques 9 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 10

6 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 11 Serviço = contracto + 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

7 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 13 Granularidade mais elevada 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 14

8 Granularidade Service Layer Component Layer Class Layer Service Oriented Design Component Oriented Design Object-Oriented Design 3/2/2005 José Alves Marques 15 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 16

9 Granularidade dos Serviços Numa arquitectura que corresponda a uma organização existente é natural que existam serviços com granularidade diferente Os serviços associados ao negócio tem uma grão grosso e são visíveis em toda a organização Serviços de grão mais fino podem corresponder a funções técnicas úteis em diversos serviços ou serviços elementares reutilizáveis Para que a arquitectura seja coerente estes serviços elementares devem poder ser facilmente agregados ou orquestrados em serviços de nível mais elevado 3/2/2005 José Alves Marques 17 Fracamente Interligado - Loosely Coupled Um serviço fracamente interligado quer dizer que se restringe o número de coisas que uma aplicação cliente que o invoca necessita de saber acerca dele. Num serviço fortemente interligado qualquer modificação no cliente ou servidor obriga a mudar o código de ambos. Esta necessidade não pode ignorar que um serviço para ser invocado necessita que as respectivas interacções tenham diversos requisitos não funcionais como segurança, atomicidade, etc. 3/2/2005 José Alves Marques 18

10 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 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 evita a existência de handles para instancias executáveis. Desenho de interfaces de serviço que não dependem de conhecimento partilhado implícito. 3/2/2005 José Alves Marques 19 Estilos de relacionamento dos serviços com os clientes Loosely Coupled Fracamente interligado Coupled Fortemente 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 como EAI com capacidade de inteligentemente efectuarem a adaptação) Negociated Se existem comportamentos que ambos suportam e a infraestrutura é capaz de negociar que seja aceitável para cada interacção Transformed Se a infra-estrutura permite a transformação para adaptar os requisitos do cliente e do servidor (ex.: adaptação de mensagens com xslt) 3/2/2005 José Alves Marques 20

11 SOA - Síntese Técnica Foco na definição de contractos para troca de informação (i.e. serviços) em vez da sua implementação Diminuir as dependências tecnológicas Desenvolver sistemas e aplicações fracamente ligados e independentes (loosely coupled systems) Adoptar modelos de comunicação assíncrona Negócio Integrar os processos de negócio com a cadeia de valor Desde a origem até ao cliente final (end-to-end) Considerando todos os subprocessos (multi-organização) Automatização da execução dos processos ao longo da cadeia de valor Eliminar/evitar constrangimentos tecnológicos (TIs) 3/2/2005 José Alves Marques 21 Do ponto de vista organizacional o SOA é uma revolução. Tecnicamente o SOA é uma evolução. Arquitectura distribuída... baseada em componentes 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 Foco na implementação ( como faz )... baseada em serviços Modelo colaborativo /eventdriven (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 Abstracção ( o que faz ) 3/2/2005 José Alves Marques 22

12 Arquitectura 3/2/2005 José Alves Marques 23 Modelação Do ponto de vista da modelação, o desafio é caracterizar e construir sistematicamente as abstracções importantes (interessantes) de operação, serviço e processo. A função das organizações (o seu negócio) deve preceder e definir as necessidades a que a arquitectura deve responder. Form follows function Louis Sullivan Chicago School of Architecture 3/2/2005 José Alves Marques 24

13 Processo de Reparação de Automóveis exemplo 3/2/2005 José Alves Marques 25 Visão OO das classe que poderiam implementar a aplicação 3/2/2005 José Alves Marques 26 13

14 Visão do modelo de Serviços 3/2/2005 José Alves Marques 27 Modelação do Processo de Negócio 3/2/2005 José Alves Marques 28

15 Orquestração dos Serviços 3/2/2005 José Alves Marques 29 Modelo de uma arquitectura de Serviços (IBM) O modelo pode ser descrito como a interacção de quatro modelos: Modelo de Informação Modelo de Organização Modelo de Serviços Modelo de Composição de Processos. 3/2/2005 José Alves Marques 30

16 Arquitectura Empresarial 3/2/2005 José Alves Marques 31 Modelação From a modeling standpoint, the resulting challenge is how well-designed operation, service, and process abstractions can be characterized and constructed systematically. We are not aware of any recent SOA project or workshop in which such service modeling aspects have not been a major topic, giving fuel for numerous debates. 3/2/2005 José Alves Marques 32

17 Como reconhecer/identificar os Serviços? Até agora, a prática tem sido a adopção de uma postura Bottom-up: Numa primeira fase, começa-se por criar serviços elementares à volta das aplicações existentes. Numa segunda fase, agrega-se estes serviços elementares em serviços mais complexos. 3/2/2005 José Alves Marques 33 Decomposição de Serviços Decompor as aplicações herdadas Encontrar os serviços reutilizáveis Orquestrar em Serviços que repliquem a funcionalidade das aplicações existentes 3/2/2005 José Alves Marques 34

18 Como reconhecer/identificar os Serviços? Contudo, esta prática: Leva à proliferação de Serviços. Ignora a dependência entre as aplicações que sustentam cada Serviço. Não estabelece regras nem orientações para a implementação de novas Aplicações. Ignora por completo o alinhamento da Informação com o Negócio e com as Aplicações. Esta prática, apenas permite definir um conjunto de serviços que fazem sentido com o conjunto de aplicações existente na organização. É aqui que o SOA liga com as Arquitecturas de Sistemas de Informação e o seu Alinhamento com o Negócio 3/2/2005 José Alves Marques 35 Business Processes Como reconhecer/identificar os Serviços? Business Services Web Services Business Components 3/2/2005 José Alves Marques 36

19 Como reconhecer/identificar os Serviços? Cada Aplicação ou Business component deve ser desagregado em: Workflows, separando o work do flow Interfaces de Web Serviçe para cada work Num ou mais sistemas de informação para suportar os works. 3/2/2005 José Alves Marques 37 Como reconhecer/identificar os Serviços? Agregando o workflow e os Serviços de cada componente temos a visão da Arquitectura SOA. Business Processes Business Services Web Services Business Components 3/2/2005 José Alves Marques 38

20 Solução tipica 3/2/2005 José Alves Marques 39 Problemas com a modelação tradicional Experience from early SOA implementation projects suggests that existing development processes and notations such as OOAD, EA, and BPM only cover part of the requirements needed to support the SOA paradigm. While the SOA approach reinforces well-established, general software architecture principles such as information hiding, modularization, and separation of concerns, it also adds additional themes such as service choreography, service repositories, and the service bus middleware pattern, which require explicit attention during modeling. 3/2/2005 José Alves Marques 40

21 Problemas com a modelação tradicional OO e UML applying OOAD techniques and the Unified Modeling Language (UML) notation on the architectural level has been common practice for many years. As a standalone use case model is frequently created per problem domain, and consequently, application development project, the enterprise-wide big picture gets blurred in many cases. Furthermore, for various reasons the use case models are not always synchronized with their BPM counterparts. 3/2/2005 José Alves Marques 41 Problemas com a modelação tradicional EA frameworks According to past experience, most existing EA frameworks have limitations in one or more areas. Many enterprise-level reference architectures and frameworks are rather generic, and do not reach down to the design domain. Such high-level architectures fail to give concrete, tactical advice for solution architects and developers; a fundamental gap between enterprise and solution architectures frequently is the consequence. However, in a SOA context, this way of thinking must be changed to one centered around logical building blocks representing business services, concentrating on defining the interfaces and Service Level Agreements (SLAs) between the services. 3/2/2005 José Alves Marques 42

22 3/2/2005 José Alves Marques 43 SOA: no processo de desenvolvimento O mundo como o conhecemos não acaba com os serviços. Nem tudo será um serviço ; Os serviços devem complementar o que existe e o que foi desenvolvido anteriormente; O ciclo de desenvolvimento deve ser adaptado Novas decisões: quando e como utilizar? quando não utilizar? Novos deliverables e preocupações de desenho /concepção Novas etapas e tipos de teste; Novos stakeholders Metodologia de desenvolvimento Análise Foco na análise Maior detalhe (automatização completa) Maior complexidade (automatização do processo de negócio completo) Concepção Segurança Performance Topologia da rede de comunicação Complexidade 3/2/2005 José Alves Marques 44