1 / 32

Prof. Wamberg Oliveira

Prof. Wamberg Oliveira. Introdução. Desenvolver software foi e continuará sendo difícil, pois nem tudo que queremos pode ser feito

yachi
Download Presentation

Prof. Wamberg Oliveira

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Prof. Wamberg Oliveira

  2. Introdução • Desenvolver software foi e continuará sendo difícil, pois nem tudo que queremos pode ser feito • Num ambiente operacional tradicional é difícil fazer a integração de softwares, já que as regras de negócio são dinâmicas e podem sofrer alterações a qualquer momento, e a área de TI deve estar preparada para assimilar essas mudanças e gerar resultados corretos e em tempo hábil. • As empresas por muito tempo têm procurado integrar sistemas existentes para dar suporte de TI para os processos de negócio atuais e para os futuros processos a serem implantados • Uma arquitetura padrão e flexível se faz necessária para dar suporte a esse processo. • SOA (Arquitetura orientada a serviços) aparece no mercado como uma possível solução para esta problemática

  3. Introdução • Unifica os processos de negócio estruturando grandes aplicações como uma grande coleção de pequenos módulos chamados serviços. • Essas aplicações podem ser usadas por diferentes grupos de pessoas da empresa, e novas aplicações podem ser construídas a partir da combinação destes serviços. • Umas das grandes promessas da SOA é o que o custo marginal para produzir uma nova aplicação é quase zero, já que existem serviços já prontos e basta combinar os serviços para ter uma nova aplicação. • Segundo prognósticos do Instituto Gartner, com 70% de probabilidade, até o final de 2008, a SOA será a prática de engenharia de software predominante, dando fim a 40 anos de dominação de arquiteturas monolíticas de softwares

  4. Definições • O termo "Service-Oriented Architecture" (SOA), ou ainda em português Arquitetura Orientada a Serviços, é um novo modelo de negócios que visa organizar os recursos de software, também conhecidos como serviços, de forma que estes possam compor os processos de negócio, atendendo assim às necessidades da empresa. • Mas para entender o que é o SOA, é necessário ter em mente o conceito de serviço, tão utilizado no mundo da TI. • O serviço é a lógica do negócio (servidor), capaz de ser acessado por outro processo (cliente). O serviço, no ponto de vista da arquitetura SOA, é uma função de negócio que implementa os processos de negócio, possuem interface bem definida, baseada em padrões abertos. • Além disso, possui a característica de poder ser disponibilizado e reutilizado em outros sistemas. • A maneira mais comum de implementar a SOA é através de Web services, que são soluções utilizadas na integração de sistemas e na comunicação entre aplicações diferentes .

  5. SOA X OO • A Arquitetura Orientada a Serviços é um paradigma utilizado no desenvolvimento de softwares, a exemplo da Orientação a Objetos (OO). • Por esse motivo, a SOA muitas vezes é confundida com a OO, mas o que ocorre é que os princípios da primeira derivaram em grande parte dos da segunda. • Quando de sua idealização, a OO foi considerada por muitos como uma solução definitiva no processo de desenvolvimento de software; porém, problemas não previstos anteriormente na orientação a objetos puderam ser elucidados com os novos recursos oferecidos pela orientação a serviços. • Desta forma, como ocorreu com a OO, é de se imaginar que, futuramente, um outro paradigma, ainda mais completo poderá complementar ou mesmo suplantar a SOA em sua totalidade.

  6. Características desejáveis • Para que uma arquitetura seja considera como orientada a serviços, ela deve apresentar uma série de características que a norteiem desde sua fase de desenvolvimento até a etapa de uso, bem como sua manutenção • Principais características • Reusabilidade • A reusabilidade é um fator importante dentro contexto da SOA, pois sendo aplicada de forma eficiente, evita gastos exorbitantes e desnecessários para as indústrias de software. Assim, tempo e verba que antes seriam destinados à realização de novas tarefas podem ser realocados para outras atividades, aproveitando-se as soluções elaboradas para situações já ocorridas. • Baixo Acoplamento • As funções de negócio (atividades) em SOA são implementadas na forma de serviços que não dependem de outros componentes para que funcionem normalmente, e que podem ser utilizados diversas vezes no sistema.Estes serviços são conhecidos como componentes independentes, que interagem entre si apenas por intermédio de interfaces bastante definidas.

  7. Características desejáveis • Principais características • Neutralidade de implementação • Essa característica denota que não existem limites a serem estabelecidos em relação ao conjunto de ferramentas (tecnologias, linguagens, plataformas) a serem utilizadas na forma de implementação em SOA. • Com a implementação de serviços, outros desenvolvedores podem usufruir destes de forma adequada, de acordo com a interface que for especificada. Mas para isso, é importante que a função do serviço seja especificada, juntamente com informações do tipo dados de entrada e de saída (E/S). Informações mais detalhadas acerca da implementação de um serviço não possuem relevância para o resto do sistema, e, por isso não deverão ser disponibilizadas.

  8. Características desejáveis • Principais características • Interoperabilidade • O desenvolvedor, ao implementar um serviço, deve especificar a função de serviço, assim como demais dados pertinentes de E/S. Para que isso ocorra, uma série de padrões e regras devem ser observados, e estes, por sua vez, foram desenvolvidos para listar todos os requisitos importantes para que um serviço seja utilizado e acessado de forma viável através de uma rede. • Com isso, notamos que a arquitetura proporciona grande liberdade de desenvolvimento, e daí se chega à abordagem da interoperabilidade, que pode ser definida como a capacidade do SOA de se comunicar de forma o mais transparente possível com outro sistema, estabelecendo uma coexistência que independe de padrões ou indústrias de tecnologia. • Desta forma, a importância deste princípio se dá porque ele proporciona a idealização e concretização de soluções de maior qualidade e flexibilidade, visto que são minadas eventuais dificuldades de comunicação entre sistemas diversos, onde cada um, por sua vez, foi implementado a partir de situações, limitações e necessidades também bastante diferentes.

  9. Características desejáveis • Principais características • Modularidade • Em SOA, a modularidade é a característica do sistema que permite que ele seja composto de várias partes – ou módulos – distribuídas em diferentes plataformas e ambientes, o que permite que se agregue soluções de alta escalabilidade e baixo custo. • Ela promove, assim, um alto nível de separação entre os componentes da infra-estrutura e os da lógica de negócio, bem como uma maior independência no desenvolvimento dos componentes de negócio, corroborando ainda para a promoção da reusabilidade. • Por não possuírem forte dependência entre si, os módulos podem ser desenvolvidos, implantados e atualizados de forma independente.

  10. Relembrar é viver

  11. SOA: Uma abordagem paraalinhar Negócios/TI • Uma abordagem diferente para arquiteturas de TI de corporações ... direcionada para negócios, não para tecnologia ... focada no compartilhamento e reuso de funcionalidades ... alinhando negócios e TI ... confiando na governança ... pode ser implementada usando qualquer tipo de arquitetura, tecnologia ou conjunto de produtos

  12. Arquitetura SOA

  13. Arquitetura SOA • Camada Corporativa • Camada responsável por identificar e gerenciar os negócios aos quais se deseja tratar com a aplicação SOA. • Camada de Processos • Camada que identifica e caracteriza os processos dos negócios definidos na camada acima. • Cada processo é único em uma determinada área funcional, podendo ser dividido em sub-processos, que podem também ser subdivididos, exibindo as dependências funcionais de um processo. • Difere de um serviço pelo fato de que um serviço deve ser reutilizável em diversos contextos, enquanto um processo é único em seu contexto. • Camada de Serviços: • Camada que mapeia os serviços disponíveis na aplicação, provendo funcionalidades básicas, técnicas e/ou de negócio.

  14. Arquitetura SOA • Camada de Componentes • Camada que mapeia os componentes que podem ser “promovidos a serviços”, pela avaliação da capacidade dos componentes serem reutilizáveis em outros sistemas. • Um serviço pode ser composto de diversos componentes, sendo estes também utilizáveis em serviços distintos. • Camada de Objetos • Identifica e caracteriza os objetos, que são utilizados no sistema. SOA estende o conceito de POO quando exige que um objeto além de ser público, possa ser importante para o sistema ao ponto de ser encapsulada como um componente, sendo em seguida incorporada a um ou mais serviços do sistema.

  15. Arquitetura SOA- Exemplo

  16. Arquitetura SOA- Exemplo • Neste gerenciador de planos de saúde – representando a camada corporativa –, é composta de dois processos, renovar conta (1) e processar seguro de vida (2). • Os processos se utilizam de alguns serviços, sendo alguns deles utilizados por ambos os processos, exemplificando sua característica de reutilização. • A camada de legado – representando a camada de componentes –, exibe coleções de objetos – as figuras menores – que são encapsulados para utilização na camada de serviços. • Por exemplo, o processo 2 utiliza, entre outros serviços, o serviço Configurar Benefícios. • Este serviço é composto de objetos que pertencem aos seguintes componentes: Sistema de Gerenciamento de benefícios, Banco de Dados de Clientes e Parceiros de Negócio.

  17. Aplicações SOA • Apache Tuscany • Integrante do projeto Apache, o Tuscany é um framework de desenvolvimento de aplicações sob a arquitetura SOA. O projeto está conforme com as especificações do grupo OpenSCA, e é dividido em três componentes: • SCA: ServiceComponentArchitecture - Arquitetura que define como criar componentes e como interliga-los para criar aplicações baseadas em serviços. Uma característica do SCA é que estes componentes não precisam necessariamente ser criados numa mesma linguagem ou tecnologia. • DAS: Data Access Service – Serviço responsável por simplificar a manipulação de dados, que podem ser desde aplicações que usam JDBC até comunicações de XML/HTTP, usado pelos Web Services, tornando simples a manutenção para o desenvolvedor. • SDO: Service Data Object: Framework que unifica o modelo de programação entre vários tipos de dados, fazendo com que possa ser utilizado mesmo modelo de lógica, programação e API, independente do tipo de dados acessados – estruturados, semi-estruturados, não-estruturados.

  18. Web Services • Uma das aplicações mais difundidas que utilizam SOA são os web services. Conceitualmente, Um web service é uma arquitetura de criação de serviços, que são distribuídos através de uma rede, mais comumente a internet. • Através do web service, os serviços podem ser reutilizados na rede por outros sistemas, sem qualquer tipo de intervenção direta dos usuários. • A comunicação entre clientes/servidores acontece através de mensagens sob o protocolo XML. • Podemos destacar como vantagens do Web Service: • Interface abstrata: Usado para ocultar do usuário os detalhes de implementação; • Dados com semântica: Além dos dados, os metadados a eles associados também são transmitidos; • Portabiliadade: O uso de XML permite que a portabilidade do sistema seja feitas em vários tipos de aplicação; • Segurança: Deve-se a possibilidade de criptografia dos dados trafegados; • Uso responsável de recursos: Os recursos utilizados não são consumidos em estado de espera.

  19. Web Services • A arquitetura dos Web Services é baseada na interação de três entidades: o Provedor de Serviços, o Solicitante de Serviços e a Agência de Descobrimento. Estas entidades se comunicam através de operações de publicação, pesquisa e ligação

  20. Web Services • Provedor de serviços: entidade que cria o Web Service, disponibiliza o serviço para que qualquer elemento da rede possa utiliza-lo. Isso é feito através da descrição do Web Service em um formato padrão, tanto para quem desejar usar o serviço quanto para hospedagem em um registro central, a Agência de Descobrimento (AD). • Solicitantes de serviços: entidade que deseja consumir algum serviço compartilhado por algum provedor de serviço. Isso é possível a partir da descrição disponibilizada pelo provedor de serviços, recuperando os seus detalhes através de uma pesquisa sobre o registro publicado. • Agência de Descobrimento: Localização central onde o provedor de serviços pode relacionar seus Web Services, e no qual um consumidor de serviços pode pesquisá-los.

  21. Web Services • A arquitetura de um Web Service também é definida pelos protocolos que são utilizados para a realização da comunicação de dados e metadados entre solicitante e provedor de serviços. Esta pilha descreve os grupos de padrões que compõem a pilha de componentes do Web Service.

  22. Web Services • HTTP: • Protocolo de Transporte utilizado para transmitir requisições na Web, baseado em requisições de clientes e respostas dos servidores; • SOAP: • SimpleObject Access Protocol– Protocolo responsável pela troca de mensagens entre os atores do Web Service. É composto de duas partes principais: uma que determina o framework de transporte de mensagens, que pode usar qualquer protocolo de transporte, mais comumente o HTTP; a outra é subdividida em: conjunto de regras para definição de tipos de dados, convenção para uso de RPC e conjunto de regras para uso do SOAP com protocolos de transporte, como o HTTP. • XML: • Extensible Markup Language – Linguagem de representação de dados semi-estruturados, o mais recomendável para o transporte dos dados através dos atores do Web Service. Para a descrição dos tipos de dados, são utilizados XML Schemas.

  23. Web Services • WSDL: • WebserviceDescriptorLanguage – Sistema de descrição de serviços. Nada mais é do que um documento XML em que são descritos os serviços disponibilizados pelo Web Service, independente de sua arquitetura ou linguagem de programação, ou seja, descreve um conjunto de mensagens SOAP e como elas serão utilizadas pela aplicação que usa o Web Service. • UDDI: Universal Description, Discovery andIntegration – • especificação utilizada para a descrição, integração e descoberta de Web Services. [4] descreve o protocolo UDDI como uma lista telefônica, sendo que as “páginas brancas” representam as informações do Provedor de Serviços – como nome, endereço, telefone –, as “páginas amarelas” representam as categorias de serviços classificadas em taxonomias padrões – como um agrupamento de empresas de uma mesma categoria – e as “página verdes” representam a interface para acessar o serviço, com detalhamento suficiente para uso no desenvolvimento de uma aplicação que utilize Web Services – como um catálogo de serviços oferecido pro uma empresa.

  24. Vantagens do SOA • O SOA oferece uma série de benefícios para entidade que fará uso do mesmo. Características como baixo acoplamento, neutralidade de implementação e reusabilidade de funções de negócio, fazem com que o SOA permita • Maior flexibilidade e adaptação • O alto nível de flexibilidade e a habilidade de se adaptar rapidamente às mudanças nos requisitos são, consideradas por muitos, como as maiores vantagens do SOA. • Segundo a arquitetura tradicional, a cada mudança em regras de negócio, vários sistemas legados deveriam ser modificados para satisfazer a mudança. • Com o SOA, basta alterar a implementação no serviço correspondente, pois o mesmo é usado por vários processos que, após esta modificação, estarão alinhados à mudança. • Interoperabilidade • O uso de padrões torna possível a concretização de uma grande vantagem no SOA: a interoperabilidade entre sistemas. • Na arquitetura tradicional, a integração entre ambientes heterogêneos necessitava o desenvolvimento de ferramentas para permitir e garantir a comunicação entre os ambientes. Geralmente, a solução era muito específica, vulnerável à mudanças e demandava alto custo. • Com SOA, a interoperabilidade no sistema é feita basicamente aplicando-se coerentemente os padrões de design adotados. • Como exemplo disso, uma aplicação JAVA pode se comunicar com um sistema Delphi na rede, bastando que ambos tenham implementado os padrões necessários.

  25. Vantagens do SOA • Diminuição de custos de Manutenção • Outra clara vantagem do SOA é a diminuição dos custos de manutenção. Antes se uma falha lógica de uma função fosse detectada ou se a mesma tivesse de ser alterada devido a mudanças nas regras de negócio, seria necessário alterar em todas as partes do sistema onde a função estivesse presente. • Com o SOA, basta alterar o serviço correspondente à funcionalidade, reduzindo assim o custo e a complexidade das tarefas de manutenção. • Reuso de Código • Em sua arquitetura, o SOA prega o encapsulamento das funcionalidades dos sistemas legados em serviços, de tal forma que se possa fazer usos destes serviços em qualquer processo de negócio. • Sendo assim, o reuso de código acaba sendo uma consequência dos paradigmas do SOA. • Além destas vantagens, existe uma grande vantagem administrativa para as entidades. • Arquiteturas baseadas no SOA facilitam o gerenciamento do crescimento dos sistemas corporativos, provendo alto nível de escalabilidade ao arquiteto, podendo diminuir drasticamente o nível de complexidade do sistema, diminuindo assim os custos com o mesmo. • Apesar das vantagens aqui citadas, a implantação do SOA ainda é um processo lento e relativamente custoso, o que é uma visível desvantagem de se implantar o SOA.

  26. Padrões SOA • Para facilitar e otimizar o desenvolvimento de aplicações em qualquer tipo de arquitetura, são criados padrões de projeto, que são porções de código com boas práticas para resolução de problemas específicos que ocorrem com freqüência, sendo disponibilizados e validados pela comunidade. • Com o padrão SOA, foi mobilizado no site SOA Patterns alguns padrões específicos criados por grupos de pesquisa e comunidade em geral para auxiliar o desenvolvimento de aplicações sob o padrão orientado a serviços. • A especificação disponibilizada pelo site SOA Patterns divide os padrões SOA em categorias: • Padrões de Projeto de Linguagem Básico para Inventário de Serviços; • Padrões de Projeto Arquiteturais; • Padrões de Projeto de Linguagem Básico para Serviços; • Padrões de Projeto de Serviços; • Padrões de Projeto de Componentes Comuns.

  27. Padrões SOA • Um exemplo com semelhanças em uma abordagem orientada a objeto, é o Padrão Service Facade, da classe de Projeto de Serviços. • Assim como numa abordagem orientada a objeto, o Facade serve para “ocultar” de outros processos – consumidores de serviços – a especificação do serviço, oferecendo a possibilidade de modificação do serviço sem impactar nos consumidores.

  28. SOA e Mercado • Aos poucos o mercado começa notar a atuação de SOA nos negócios. Isso porque, quem utiliza SOA consegue oferecer novos serviços rapidamente, o que pode acontecer por meio de sistemas de TI novos ou existentes. • Uma pesquisa feita nos Estados Unidos pelas revistas CIO e Computerworld identificou que 58% dos 612 executivos de TI entrevistados implementou o conceito ou pretendem implantar o SOA a curto prazo. • Aproximadamente 44% deles utilizarão SOA para integrar aplicações internamente, 28% para fornecer serviços a clientes ou consumidores e 21% para se conectarem com aplicações externas fornecidas por parceiros. • Uma pesquisa feita em Portugal pela IDC analisou que será o mercado de TI no período entre 2005 e 2009. • O resultado mostrou que mais da metade dos investimentos será direcionada para hardware, seguido de serviços e softwares. • A estimativa também é que haja um aparecimento cada vez maior de tecnologias e ferramentas de desenvolvimento orientadas para a implementação de soluções SOA.

  29. SOA e Mercado • Aos poucos o mercado começa notar a atuação de SOA nos negócios. Isso porque, quem utiliza SOA consegue oferecer novos serviços rapidamente, o que pode acontecer por meio de sistemas de TI novos ou existentes. • Uma pesquisa feita nos Estados Unidos pelas revistas CIO e Computerworld identificou que 58% dos 612 executivos de TI entrevistados implementou o conceito ou pretendem implantar o SOA a curto prazo. • Aproximadamente 44% deles utilizarão SOA para integrar aplicações internamente, 28% para fornecer serviços a clientes ou consumidores e 21% para se conectarem com aplicações externas fornecidas por parceiros. • Uma pesquisa feita em Portugal pela IDC analisou que será o mercado de TI no período entre 2005 e 2009. • O resultado mostrou que mais da metade dos investimentos será direcionada para hardware, seguido de serviços e softwares. • A estimativa também é que haja um aparecimento cada vez maior de tecnologias e ferramentas de desenvolvimento orientadas para a implementação de soluções SOA.

  30. SOA e Mercado • Porém, vale ressaltar que a adoção desse tipo de arquitetura é um processo que deve acontecer em longo prazo, principalmente porque, para que as organizações concretizem o conceito na realidade corporativa, será preciso uma série de providências que vão desde a preparação tecnológica e pessoal até o nível de consolidação dos sistemas. • Pode-se notar que o mercado está adotando o SOA, porém, de uma forma ainda receosa, progressiva e controlada a fim de evitar transtornos nos sistemas de informação das empresas.

More Related