Post on 14-Dec-2018
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
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
attribute:Type = initialValue
attribute:Type = initialValue
operation(arg list):return type
Class Name
attribute:Type = initialValue
attribute:Type = initialValue
attribute:Type = initialValue
operation(arg list):return type
0..1 1...*
Class Name
attribute:Type = initialValue
attribute:Type = initialValue
attribute:Type = initialValue
operation(arg list):return type
Class Name
attribute:Type = initialValue
operation(arg list):return type
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
Características desejáveis
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
Características desejáveis
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
Características desejáveis
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
Características desejáveis
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
Características desejáveis
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
Características desejáveis
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
Características desejáveis
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
Arquitetura SOA- Exemplo
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
Arquitetura SOA- Exemplo
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