Desenvolvimento de Sistemas - Iníciobacala/SOA/SOA01-Introducao.pdf · Distribuída: os elementos funcionais da aplicação são utilizados em múltiplos sistemas (provedor,

Desenvolvimento de Sistemas

Abstrações de um Sistema

Utiliza um conjunto selecionado de conceitos e regras de forma a focar em aspectos específicos de interesse num sistema.

Visão do Sistema Representação de um sistema a partir da

perspectiva de um ponto de vista definido.

Ponto de Vista ou Visão de um Sistema

Banco de Dados

•Conceitual

•Lógico

•Físico

Envolvidos

•Usuário

•Arquiteto

•Implementador

Visão do

Estilo

Estilo Arquitetônico

barroco

Visão do

Projeto

Projeto da Arquitetura

Projeto de Engenharia

plantas

Visão da

Realidade

Construção

Igreja Bom Jesus de

Matosinhos

Desenvolvimento Predial

http://images.google.com/imgres?imgurl=www.infocadiz.com/museos/plano2.gif&imgrefurl=http://www.infocadiz.com/museos/planta2.htm&h=357&w=597&prev=/images?q=barroco&start=160&svnum=10&hl=en&lr=&ie=UTF-8&oe=UTF-8&sa=N

Visões da Arquitetura

Arquitetura Corporativa

Composta de:

Arquitetura de Negócios

Arquitetura de Dados

Arquitetura das Aplicações ( Sistemas )

Arquitetura da Tecnologia da Informação

São orientados pelo

Estilo da Arquitetura

Estilo da Arquitetura

princípios e os meios que permitem que se obtenha

de forma mais efetiva a VISÃO DE PROJETO

Estilos de Arquitetura Disponíveis

Modelos Visuais

Baseado em Objetos

Baseado em Componentes

Baseado em Processos de

Negócios

Orientado a Serviços

Baseado em Eventos

Arquitetura de Sistemas – Necessidade

Toda a aplicação (conjunto de aplicações) tem uma arquitetura na qual foi construída (mesmo que no seu desenvolvimento ela não tenha sido considerada)

Uma arquitetura mal construída tornará a aplicação difícil de desenvolver, administrar e modificar

Uma boa arquitetura elevará o nível de flexibilidade, controle e reusabilidade que se tem sobre a aplicação, o que tem como consequência a diminuição do tempo de desenvolvimento

Solução mais comum sobre Arquitetura

Aplicação B Aplicação C Aplicação A

Arquitetura

Aplicação

B

Arquitetura

Aplicação

C

Arquitetura

Aplicação

A

•Investimento redundante em arquiteturas não

adequadas

•Ciclo de desenvolvimento redundantes

•Maiores custos de projeto e manutenção da

aplicação

•Má utilização dos recursos

Solução atual sobre Arquitetura

Aplicação C Aplicação A Aplicação B

Arquitetura

Com Estilo

Consistente

•Arquitetura reusável e provada

•Desenvolvimento mais rápido e sustentável

•Ação gerencial simplificada

•Aplicações flexíveis capazes de responder a requisições

de mudança

Fazem com que a estrutura do sistema:

• dependa da visão de baixo nível

(tecnologia )

•seja definida no início do

desenvolvimento ( mudança nos

requisitos invalidam tudo)

•não tenha nada com o domínio do

problema

Metodologias Clássicas Resultam em sistemas difíceis de:

•Acompanhar

•Manter

•Modificar

Funcional

Dados

Processos

Diagrama de Fluxo de Dados

Modelo de Entidade e Relacionamentos

Modelos Orientados a Objetos

Diagramas da UML

Correspondência clara entre os modelos dos domínios do

problema, do projeto e da implementação

Class Name

attribute:Type = initialValue



operation(arg list):return type

Class Name





0..1 1...*

Class Name





Class Name



Desenvolvimento de Sistemas Orientados a Objetos

Necessita ambientes de desenvolvimento extremamente rigorosos e formais, com pessoal altamente treinados

Nos grandes projetos abstrações corretas são difíceis de realizar

Modelos de objeto mal realizados criam mais problemas do que soluções

O nível de granularidade dos objetos é muito baixo, o que torna complexo o controle da dependência entre eles

Componentes

Definição:

Um pequeno grupo de objetos trabalhando agrupados a fim de prover uma função do sistema

Os objetos dentro do componente não são conhecidos por outra parte do sistema, exceto pelo próprio componente

Características dos Componentes

Tem todas as características de um objeto

Tem limites impostos pela plataforma para a qual foi projetado

Podem existir independentes dos outros componentes, exceto daqueles que usa na mesma plataforma

Tem interface fixa e comum a todos os demais componentes do sistema

São auto descritos (seus clientes sabem como usá-los )

Componentes de Software

Conjunto discreto, administrável de lógica

Código que implementa um conjunto pré-definido de interfaces

Não são aplicações inteiras

Não rodam sozinhos

São usados como peças de quebra-cabeça para resolver um problema maior

Um componente que resolve um determinado problema pode ser comprado e combinado com outros para resolver um problema maior

Componente de Software: Exemplo

Componente Cálculo de Preço Final

Manuseia informações sobre o preço de um conjunto de

produtos, fornecendo o preço total da compra

Baseado num conjunto de Regras de Definição de Preços

•Preços unitários dos produtos

•Quantidade de itens de produto comprados

•Desconto de quantidade/ cliente / região

•Sobretaxas ( impostos, transporte )

Pode ser Usado:

•Serviço de Correio para definir o preço de remessa de pacotes

•Fabricante de automóveis para descriminar o preço do automóvel

vendido

Separação da Interface e da sua Implementação

Interface do Componente

•Define o contrato do componente com o código do outro

componente que o chama

•Esconde de seus clientes os detalhes de sua construção

•Permite que seus clientes somente tratem com os resultados

finais de suas próprias operações

Implementação do Componente

•Lógica da programação interna, escondida de seus clientes

•Pode ser mudada sem alterar do código de seus clientes

Desenvolvimento Baseado em Componentes

Um sistema complexo pode ser considerado como um conjunto composto de um número arbitrário de pequenos sistemas coesivos ( componentes )

Cada componente é construído para implementar um conjunto definido de responsabilidades

Cada componente é auto contido e acoplado a outros componentes

Componentes são projetados para serem utilizados dentro de uma plataforma que integra todos os componentes numa aplicação

Compone nt

Compone nt

Compone nt

Plataforma baseada em Componentes

Deve conter:

Ferramentas para desenvolver componentes

Um Container para gerenciar os componentes utilizados: Ambiente runtime para executar os componentes

Inclui conjunto de serviços que os componentes necessitam

Ferramentas para implementação e manutenção

Customização de componentes para ambientes específicos

•Facilita a construção, administração e manutenção

de componentes

•Deve ser padronizada

Plataforma baseada em Componentes

Permite o desenvolvimento e a utilização de sistemas baseado em componentes

Cria instâncias runtime de componentes

Permite a componentes descobrir e se comunicar com outros componentes

Provê serviços comuns adicionais, como:

Persistência

Transações

Independência de localização

Segurança

Monitoramento

Uso de Componentes: Vantagens

Técnicas

•A complexidade é melhor administrada, permitindo melhor

qualidade nas soluções

•Funcionalidade técnicas ( não de negócios ) é concentrada na

plataforma

Negócios

•Produtos de melhor qualidade

•Tempo menor para desenvolvimento de sistemas

•Melhor utilização de recursos humanos

•Habilidade de resposta a mudanças

•Custo reduzido

•Alto reuso para projetos futuros

Uso de Componentes: Desvantagens

Os componentes fortemente acoplados:

uma mudança no código de um deles pode levar a mudanças nos demais

A administração da complexidade da dependência entre os componentes em grandes sistemas é difícil:

um componente ainda tem que saber muito sobre os demais (aos quais se acopla)

As soluções proprietárias:

DCOM – MS, CORBA

Um comportamento provido por

um componente, baseado

somente numa interface do tipo

de contrato

O conjunto de contratos ( sub-serviços )

caracteriza um serviço de negócios

Serviço

Visão de Serviços de Negócios

•Tem um contrato, o qual consome e produz

Documentos de Negócios

•Integra várias aplicações para resolver

Problemas de Negócios

Não se pensa em linhas

de código Java ou Cobol

Em vez de se ver

dados

Serviço: Capacitação em Inglês no nível B

Consumidor: Aluno

Provedor: Escola

Contrata

Procura / Coordena / Integra sub-serviços:

Aluguel da sala, Limpeza, Pintura,

Oferta de aulas, Instalação do Laboratório

Diretório de Serviços disponíveis

Jornal

Páginas Amarelas

Lógica de Negócios

Dados Apresentação

Publicação

SOA

SOA - Características Arquiteturais

Distribuída: os elementos funcionais da aplicação são utilizados em múltiplos sistemas (provedor, consumidor, publicador), localizados em pontos diferentes

Acoplamento Fraco: as ligações entre os elementos funcionais não são fixas ou rígidas, podendo ser assíncronas

Escalável: novos elementos podem ser agregados, um serviço pode ser composto de outros serviços, sistemas legados, sistemas de pacotes

Baseada em Padrões: independente de vendedores específicos

Integrados por XML

Tecnologias Básicas dos Serviços Web Services

Conjunto de padrões tecnológicos

emergentes:

WSDL – Web Services Defination Language

UDDI – Universal Description Descovery and

Integration

SOAP – Simple Object Acess Protocol

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.

32

Introdução

As empresas 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

Faz-se necessária uma arquitetura padrão e flexível 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

33

Introdução

SOA 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.

34

Introdução

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, SOA será a prática de engenharia de software predominante, dando fim a 40 anos de dominação de arquiteturas monolíticas de softwares

35

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.

36

Definições

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.

Também possui a característica de poder ser disponibilizado e reutilizado em outros sistemas.

A maneira mais comum de implementar a SOA:

Web services, que são soluções utilizadas na integração de sistemas e na comunicação entre aplicações diferentes .

37

SOA

Arquitetura que tem tido destaque na integração de negócios atualmente.

SOA segundo a Accenture:

“Uma arquitetura que define como funções de negócios distintas, implementadas por sistemas autônomos, devem operar conjuntamente para executar um processo de negócio.”

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.

39

SOA X OO

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.

40

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, tais como baixo acoplamento, reusabilidade, neutralidade de implementação, ...

41


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.

42


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.

43


Neutralidade de implementação

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.

44


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.

45


Interoperabilidade

Nota-se que a arquitetura proporciona grande liberdade de desenvolvimento, chegando-se à 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.

46


Interoperabilidade

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.

47


Modularidade

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.

Promove um alto nível de separação entre os componentes da infraestrutura e os da lógica de negócio, e uma maior independência no desenvolvimento dos componentes de negócio, promovendo a reusabilidade.

Por não possuírem forte dependência entre si, os módulos podem ser desenvolvidos, implantados e atualizados de forma independente.

48

Relembrar é viver

49

SOA: Uma abordagem para alinhar 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

que pode ser implementada usando qualquer tipo de arquitetura, tecnologia ou conjunto de produtos

50

Arquitetura

Cada função de negócio (componente) é im-plementada como um serviço.

Esses serviços ficam disponíveis em uma re-de para que as aplicações possam utilizá-los. Em geral, esta rede é a internet e os serviços são chamados de web services.

Características da arquitetura

As partes (serviços) são bastante indepen-dentes entre si.

Não há limitações em relação à plataforma ou à linguagem utilizada para implementar um serviço, apenas em relação a como eles comunicam-se.

Um serviço encapsula uma lógica de negó-cio. Assim, temos um alto índice de reapro-veitamento.

Arquitetura SOA

53

Arquitetura SOA

Camada Corporativa

Camada responsável por identificar e gerenciar os negócios aos quais se deseja tratar com a aplicação SOA.

54

Arquitetura 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.

55

Arquitetura SOA

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.

56

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.

57

Arquitetura SOA

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.

58

Arquitetura SOA- Exemplo

59


Este gerenciador de planos de saúde – representando a camada corporativa –, é composto de dois processos:

renovar conta e

processar seguro de vida

Os processos se utilizam de alguns serviços, sendo alguns deles utilizados por ambos os processos, exemplificando sua característica de reutilização.

60


A camada de legado – representando a camada de componentes –, exibe coleções de objetos 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.

Serviço é composto de objetos que pertencem aos componentes:

Sistema de Gerenciamento de benefícios,

Banco de Dados de Clientes e

Parceiros de Negócio. 61

Web Services

Uma das aplicações mais difundidas que utilizam SOA são os web services.

Web service é uma arquitetura de criação de serviços, distribuídos por meio de uma rede, 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.

62

Vantagens do Web Services

Interface abstrata:

oculta 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;

Portabilidade:

O uso de XML permite a portabilidade do sistema 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.

63

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. Que se comunicam através de operações de publicação, pesquisa e ligação

64

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).

65

Web Services

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.

66

Web Services

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.

67

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.

68

Web Services

HTTP:

Protocolo de Transporte utilizado para transmitir requisições na Web, baseado em requisições de clientes e respostas dos servidores;

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.

69

Web Services

SOAP (Simple Object 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;

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.

70

Web Services

WSDL (Webservice Descriptor Language ):

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.

71

Web Services

UDDI (Universal Description, Discovery and Integration) :

especificação utilizada para a descrição, integração e descoberta de Web Services.

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.

72

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:

73

Vantagens do SOA

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 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.

74

Vantagens do SOA

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.

75

Vantagens do SOA

Interoperabilidade

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.

76

Vantagens do SOA

Diminuição de 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.

77

Vantagens do SOA

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.

78

Vantagens do SOA

Existe, também, 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 dessas vantagens, a implantação do SOA ainda é um processo lento e relativamente custoso, uma visível desvantagem de se implantar o SOA.

79

Padrões SOA

Para facilitar e otimizar o desenvolvimento de aplicações em qualquer tipo de arquitetura são criados padrões de projeto,

porções de código com boas práticas para resolução de problemas específicos que ocorrem com frequê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.

80

Padrões SOA

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.

81

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.

82

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.

83

SOA e Mercado

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 pela IDC analisou que será o mercado de TI em Portugal. 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.

84

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.

85

SOA e Mercado

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 vem adotando o SOA, porém, de uma forma progressiva e controlada a fim de evitar transtornos nos sistemas de informação das empresas.

86

Documents

Desenvolvimento de Sistemas - Iníciobacala/SOA/SOA01-Introducao.pdf · Distribuída: os elementos funcionais da aplicação são utilizados em múltiplos sistemas (provedor,