monografia soa
TRANSCRIPT
UNIVERSIDADE FEDERAL DE VIÇOSA
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓCIAS
DEPARTAMENTO DE INFORMÁTICA
ARQUITETURA ORIENTADA A SERVIÇO: MAIOR INTERAÇÃO ENTRE
ESTRATÉGIA DE NEGÓCIO E A TECNOLOGIA DA INFORMAÇÃO.
GEOVANE FRANCISCO CAETANO
VIÇOSA
MINAS GERAIS – BRASIL
2008
GEOVANE FRANCISCO CAETANO
ARQUITETURA ORIENTADA A SERVIÇO: MAIOR INTERAÇÃO ENTRE
ESTRATÉGIA DE NEGÓCIO E A TECNOLOGIA DA INFORMAÇÃO.
Monografia apresentada ao
Departamento de Informática, como parte das
exigências do curso de Pós-Graduação Lato
Sensu em Ciência da Computação, da
Universidade Federal de Viçosa.
ORIENTADOR
Mauro Nacif Rocha
VIÇOSA
MINAS GERAIS – BRASIL
2008
I
GEOVANE FRANCISCO CAETANO
ARQUITETURA ORIENTADA A SERVIÇO: MAIOR INTERAÇÃO ENTRE
ESTRATÉGIA DE NEGÓCIO E A TECNOLOGIA DA INFORMAÇÃO.
APROVADA EM____/____/______
PROF. JOSÉ LUIZ BRAGA
PROF. JUGURTA LISBOA FILHO
PROF. MAURO NACIF ROCHA – INF/UFV
(ORIENTADOR)
VIÇOSA
MINAS GERAIS – BRASIL
2008
II
AGRADECIMENTOS
Agradeço primeiramente a Deus pela paz, saúde e pela força concedida nesta
caminhada e conquista.
E claro que não posso prosseguir sem agradecer minha família e amigos que
sempre me apoiaram e estenderam suas mãos nos momentos necessários.
Sou especialmente grato a minha noiva Nair Alves pela compreensão, carinho e
energia positiva que pacientemente aceitou minha ausência nos últimos meses enquanto
estava ocupado trabalhando neste projeto.
Também não posso esquecer de agradecer meus colegas de trabalho que
diretamente ou indiretamente estão contribuindo para que este projeto seja concluído com
êxito.
E os meus sinceros agradecimentos ao orientador, Mauro Nacif, pelo apoio,
dedicação e interesse neste estudo e desenvolvimento deste tema. E a todos os professores
do departamento de informática da UFV, que não mediram esforços para contribuir na
minha especialização e formação profissional.
III
SUMÁRIO
LISTA DE FIGURAS....................................................................................................... VI
LISTA DE TABELAS..................................................................................................... VII
LISTAS DE ACRÔNIMOS E SIGLAS......................................................................... VIII
RESUMO.......................................................................................................................... X
1. INTRODUÇÃO............................................................................................................. 1
2. Visão Geral da SOA..................................................................................................... 3
2.1. Definição............................................................................................................... 3
2.2. Conceito de SOA................................................................................................... 4
2.2.1.Visão o que é serviço...................................................................................... 4
2.2.2.Interoperabilidade........................................................................................... 5
2.2.3.Acoplamento fraco.......................................................................................... 6
2.3. XML........................................................................................................................7
2.4. Web services........................................................................................................... 9
2.5. Os passos para adoção da SOA..............................................................................10
2.6. SOA no Brasil, como e quando implantar.............................................................14
2.7. Governança em SOA............................................................................................. 153. Tecnologia Base da SOA.............................................................................................. 17
3.1. Padrões.................................................................................................................. 17
3.1.1.WS-*.............................................................................................................. 17
3.1.1.1.WSDL....................................................................................................18
3.1.1.2.SOAP.................................................................................................... 24
3.1.1.3.UDDI.................................................................................................... 27
4. Responsabilidade de um ESB (Barramento de serviço corporativo) em SOA.............30
4.1. Principais diferenças entre ESBs........................................................................... 33
4.1.1.ESB com conexões ponto-a-ponto e mediação..............................................33
4.1.2.ESB com interceptores...................................................................................35
4.1.3.ESB orientado a protocolo e orientado a API................................................ 37
5. Segurança em um ambiente fracamente acoplado........................................................ 39
5.1. Autenticação e autorização.................................................................................... 39
5.2. Privacidade e integridade.......................................................................................40
IV
5.3. Inundação...............................................................................................................41
5.4. Auditoria.................................................................................................................42
6. Estudo de caso baseado em grandes empresas que implementaram SOA.................... 43
6.1. Comcast..................................................................................................................43
6.2. Leapfrog Enterprise............................................................................................... 45
6.3. United Arline......................................................................................................... 46
6.4. Thomson Financial................................................................................................ 48
6.5. Jabil Circuit........................................................................................................... 49
7. Conclusão..................................................................................................................... 52
Bibliografia......................................................................................................................... 53
V
LISTA DE FIGURAS
Figura 1.1 - Conexões para integração em um sistema não SOA..........................................1
Figura 2.1 - Processo de Faturamento usando vários serviços.............................................. 4
Figura 2.2 - Interoperabilidade usando interface em EAI..................................................... 6
Figura 2.3 - Exemplo de um arquivo XML...........................................................................8
Figura 2.4 - Comunicação web service entre um consumidor e fornecedor usando o
protocolo SOAP...................................................................................................................10
Figura 2.5 - Dependências entre a infra-estrutura e múltiplos projetos.............................. 13
Figura 3.1 - Estrutura geral de arquivo WSDL 1.1 e 2.0.....................................................19
Figura 3.2 - Estrutura de uma mensagem em SOAP........................................................... 26
Figura 3.3 - Modelo UBR. Broker, fornecedor e consumidor............................................. 28
Figura 4.1 – Aplicação chamando serviços sem o uso do ESB........................................... 30
Figura 4.2 – Aplicação cliente chamando serviços pelo ESB............................................. 31
Figura 4.3 – Componentes de um ESB................................................................................32
Figura 4.4 – Exemplo ESB fornecendo conexões ponto-a-ponto........................................34
Figura 4.5 – Exemplo de conexões mediadas por ESB....................................................... 35
Figura 4.6 – ESB utilizando um único interceptador para vários fornecedores como
balanceador de cargas.......................................................................................................... 36
Figura 4.7 – ESB utilizando interceptador para cada fornecedor........................................ 36
Figura 4.8 - ESB com conexões orientadas a protocolo...................................................... 37
Figura 4.9 - ESB com conexões orientadas a APIs............................................................. 37
Figura 4.10 – Camadas do código de negócio até o código de protocolo............................38
Figura 5.1 – Modelo de segurança em uma aplicação tradicional com firewall e web
service sem segurança.......................................................................................................... 40
Figura 5.2 – Interceptação, roteamento e modificação das mensagens SOAP por um
Hacker ou pessoa não autorizada......................................................................................... 41
Figura 5.3 – Inundação com requisição ao serviço em uma SOA não segura.....................42
VI
LISTA DE TABELAS
Tabela 01 – Assuntos típico a ser considerado na implementação do acoplamento fraco em
um sistema............................................................................................................................. 7
Tabela 02 – Outros itens que fazem parte de uma governança SOA...................................16
Tabela 03 - Descrição de um arquivo WSDL na versão de WSDL 1.1...............................20
Tabela 04 - Descrição de um arquivo WSDL na versão 2.0 com SOAP 1.2...................... 22
Tabela 05 - Requisição SOAP usando protocolo http......................................................... 26
Tabela 06 - Resposta SOAP usando protocolo http.............................................................27
VII
LISTAS DE ACRÔNIMOS E SIGLAS
API - Application Programming Interface.
AS1 - AS1 Applicability Statement 1.
AS2 - AS1 Applicability Statement 2.
BUS - Biderectional Universal Switch.
BT - Business Technology.
CIO - Chief Information Officer.
DOS - Denial of Service.
EAI - Enterprise Application Integration.
EDA - Event Driven Architecture.
ERP - Enterprise Resource Planning.
ESB - Enterprise Service “BUS”.
FTP - File Transfer Protocol.
IDC - International Data Corporation.
HTTP - Hypertext Transfer Protocol.
IDE - Integrated Development Environment.
JMS - Java Message Service
MEP - Message Exchange Patterns
OASIS -Organization for the Advancement of Structured Information Standards.
REST - Representational State Transfer.
RH - Recursos Humanos.
RPC - Remote Procedure Calls.
SAP - Systemanalyse and Programmentwicklung.
SMTP - Simple Mail Transfer Protocol.
SSL - Secure Socket Layer.
SOA - Service Oriented Arquitecture.
SOAP - Simple Object Acess Protocol
TCP - Transfer Control Protoco.
TI - Tecnologia da Informação.
UBR - UDDI Business Registry.
UDDI-Universal Description, Discovery, and Integration.
VIII
URL - Uniform Resource Location.
XML - EXtensible Markup Language.
XP - Extreme Progamming.
VANs - Value Added Networks.
WSDL - Web Service Description Language.
W3C - World Wide Web Consortium.
WS-I - Web Services Interoperability Organization.
VPN - Virtual Private Network.
IX
Resumo
Um dos principais objetivos do departamento de TI é alcançar a eficiência em uma corporação, oferecendo maior flexibilidade para adaptar às necessidades de negócios que sempre estão em mudanças. Mas esta tarefa não é simples e tem exigido grandes esforços dos lideres e gestores de TI e mesmo assim, na maioria das vezes fica impossível, em tempo hábil acompanhar a regras impostas pelos analistas de negócios ou até mesmo uma demanda de mercado.
Para aliar a TI a estratégia de negócio, permitir uma tomada de decisão precisa e muito mais rápida, será apresentado neste estudo uma nova metodologia, chamada de SOA, onde a arquitetura dos sistemas de informação é baseada em serviço orientado, ou seja, todo sistema será divido em blocos de funcionalidades que poderão ser ordenados ou reordenados sem nenhuma restrição e com mínimo de esforço e custo.
X
1 Introdução
Em busca de maior flexibilidade, o mundo dos negócios em que vivemos é cada
vez mais desafiador, e a busca constante por inovação, tornou uma estratégia não só para
empresa, mas para paises [TAURION, 2007].
Fundamentado nessa constante busca por inovação, ultimamente o departamento
de TI nas empresas estão convivendo com várias gerações de tecnologia diferentes. E
pode-se afirmar que o resultado de uma grande parcela dos esforços, energia e
investimento é gasto nas atividades de manutenção e integração das aplicações. Para criar
estas integrações, geralmente as ligações entre as aplicações são feitas ponto a ponto e a
fórmula para integração é n(n-1) de conexões, onde n é o número de aplicações existentes,
demonstrado na figura 1.1. Sendo assim, uma empresa que tem dez aplicações ativas, se
desejarem fazer uma integração total serão necessárias 90 conexões e cada uma delas terá
que entender as características das outras aplicações e conseqüentemente quando esta
empresa precisar mudar seus processos ou as regras de negócios, a TI responderá de forma
muito lenta, porque todas as conexões devem ser avaliadas ou modificadas [TAURION,
2007].
Figura 1.1 – Conexões para integração em um sistema não SOA. Fonte Caetano (2008).
Paralelamente a esse caminho complexo, sem flexibilidade e árduo, caminha e
ganha força uma metodologia chamada SOA acrônimo de Service Oriented Architecture
(Arquitetura orientada a serviço).
1
A metodologia SOA propõe mudança no contexto de integração, o princípio é
dissolver as aplicações em vários serviços, conhecido pelo termo em inglês “Building
Blocks”, o que possibilita o agrupamento e/ou reagrupamento, quantas vezes for necessário
para construção de novas aplicações ou readequações aos novos processos e mudanças nas
regras de negócios. Seguindo este princípio pode-se comparar com um brinquedo “lego”
para exemplificar, onde com as mesmas peças podemos montar diversos objetos diferentes.
Na metodologia SOA as peças do brinquedo “lego” seriam os serviços e os objetos seriam
as aplicações. Seguindo este conceito, mudar as regras ou processos de negócios, seria
apenas uma nova remontagem de blocos de serviços. Não existindo custo e tempo para
desenvolvimento de novas aplicações [CESAR, 2006].
Seguindo o caminho do SOA a TI daria uma grande salto na evolução, passando a
ser uma BT (Business Techonology) assumindo a parte essencial e estratégia dos negócios
da empresa, segundo Taurion (2007).
Um dos principais benefícios do SOA é a garantia de maior longevidade que ela
proporciona aos sistemas e este projeto só valerá a pena se houver alinhamento entre
tecnologia e os objetivos de negócios da organização [NEXTGENERATION,2007].
2
2 Visão Geral da SOA
Neste tópico será abordado um parecer técnico dos recursos envolvidos em uma
implementação SOA, tais como: Definição; Conceito de serviços, interoperabilidade e
acoplamento fraco; Passos para adoção; SOA no Brasil e governança em SOA.
2.1 Definição
Pesquisadores afirmam que definir SOA é uma tarefa muito complicada, já que se
trata de um conceito abstrato, que pode ser utilizado de diversas formas e se transforma em
ferramenta específica de acordo com o negócio e com a empresa que decide adotá-la
[NEXTGENERATION, 2007]. Mas como ponto importante é que SOA tem como base e
componente fundamental o conceito de serviço, outra característica muito interessante do
SOA é a possibilidade do reuso de software, que reduz custo e esforço no desenvolvimento
e permite um atendimento aos novos requisitos com maior agilidade.
Em um ambiente SOA, os recursos de uma rede são disponibilizados como
serviços independentes e podem ser alocados ou acessados sem conhecimento da
plataforma e linguagem que foram implementados.
“SOA também pode ser conceituada como um estilo de arquitetura de sistemas
de informação que possibilita a criação de aplicações que são construídas ao se
combinarem os serviços fracamente acoplados e que funcionam em conjunto. Estes
serviços operam entre si com base em uma definição formal (ou contrato, por exemplo,
WSDL) que é independente da plataforma e da linguagem de programação. A definição da
interface esconde a implementação do serviço especifico da linguagem. Os sistemas
compatíveis com SOA podem, portanto ser independentes das tecnologias de
desenvolvimento e plataformas (como Java, .Net, etc)”-(Josuttis, 2007)
SOA não é uma arquitetura concreta, uma ferramenta ou framework com
possibilidade de compra e venda, mas sim, um paradigma, conceito, perspectiva, filosofia
ou representação e até mesmo uma estratégia metodológica da TI que decide adotá-la e
personalizá-la de acordo com cenários da empresa. Como ponto positivo e para maior
estimulo, uma aplicação SOA, normalmente é baseada em padrões de web services, o que
3
permite maior interoperabilidade com independência de padrões, conhecidos como
especificação dos web services (SOAP ou REST), ambos com amplo apoio da indústria
nos dias atuais. Outro ponto positivo é que SOA não necessariamente prende nenhuma
empresa de software proprietário. No entanto ela pode ser implementada com uso de
qualquer tecnologia baseada em serviço.
2.2 Conceito de SOA
Segundo Josuttis (2007) em seu livro “SOA na prática” os principais conceitos
técnicos que permitem lidar com as características de sistemas SOA são: Serviços,
Interoperabilidade e acoplamento fraco.
2.2.1 Visão o que é serviço.
Serviço são porções conhecidas como componentes de software, construídos de
uma forma que possa facilmente ser utilizada em outro componente para construir outro
software ou atender um determinado requisito conforme a figura 2.1, onde o exemplo
aborda um sistema de faturamento de uma indústria específica.
Figura 2.1 – Processo de Faturamento usando vários serviços. Fonte [ERL, 2005]
4
A idéia de serviço é definir partes dos códigos de software em porções
significativas o suficiente para serem compartilhadas e utilizadas em diversas áreas da
empresa. Vejamos o exemplo da figura 2.1 acima, onde o serviço busca status produtivo do
pedido, que no determinado momento esteja sendo usado pelo serviço de faturamento e ao
mesmo tempo ele poderá ser alocado em outros departamentos para atender outros
requisitos como: controle de produção, estimativa de entrega pelo departamento de
logística e até mesmo o sistema do portal disponível na web.
2.2.2 Interoperabilidade.
Interoperabilidade é a capacidade de resolver o problema de integração
facilmente entre sistemas heterogêneos. A idéia de interoperabilidade surgiu com EAI, um
conceito de integração de aplicação corporativa. Diferentemente de SOA em uma
aplicação baseada em EAI a interoperabilidade é feita criando interfaces, ou seja, softwares
que tinham o propósito de traduzir e auxiliar na comunicação entre sistemas ou
plataformas diferentes, conforme figura 2.2.
5
Figura 2.2 – Interoperabilidade usando interface em EAI. Fonte [PULIER e
TAYLOR,2007].
No entanto, para SOA o conceito de interoperabilidade é o começo para uma
implementação SOA, é também a base a partir da qual começamos a implementar as
funcionalidades de negócios(serviços) e é espalhada pelos diversos sistemas distribuídos
existentes[JONES, 2006].
2.2.3 Acoplamento fraco.
Como o SOA é aplicado em sistemas distribuídos, a escalabilidade e a tolerância
às falhas são as chaves para o sucesso e manutenibilidade dos sistemas envolvidos e
também possibilita minimizar os impactos das modificações e das falhas dentro dos
sistemas.
“O objetivo importante é minimizar o impacto das modificações e das falhas
dentro do cenário do sistema como um todo.” -(Josuttis, 2007).
Para resolver este problema imposto neste cenário, existe dentro do SOA um
conceito chamado de acoplamento fraco, onde o objetivo é minimizar as dependências
6
tipicamente empregadas para lidar com os requisitos de escalabilidade, flexibilidade e
tolerância às falhas.
“Quando existem poucas dependências, as modificações ou as falhas em um
sistema terão menos conseqüência em outros sistemas.” -(Josuttis, 2007).
O acoplamento fraco não é uma ferramenta e nem uma lista de verificações.
Portanto para projetar uma SOA é necessário definir quais tipos e qual quantidade de
acoplamento fraco serão introduzidos. No entanto, será apresentado uma tabela a seguir
com alguns assuntos típicos para considerar na implementação do acoplamento fraco no
sistema.
Tabela 01 – Assuntos típicos a ser considerado na implementação do acoplamento fraco
em um sistema.
Tipo Acoplamento forte Acoplamento
fracoConexões físicas Ponto a ponto Através de mediadorEstilo de comunicação Síncrona AssíncronaModelo de dados Tipos comuns complexos Apenas tipos comuns
simplesSistema de tipagem Forte FracoPadrão de integração Navegar através de árvores de
objetos complexos
Mensagens
independentesControle de lógica de
processos
Controle central Controle distribuído
Ligação Estática DinâmicaPlataforma Dependências de plataformas fortes Independência de
plataforma.Transações 2PC(Commit em duas fases) CompensaçãoDeployment Simultâneo Em tempos diferentesControle de versões Atualizações explícitas Atualizações implícitas
Considerações proposta por Josuttis (2007).
2.3 XML
A inspiração para o projeto de XML veio de duas fontes distintas: SGML
(Standard Generalized Markup Language) e HTML(Hypertext Markup Language). A
versão 1.0 de XML foi disponibilizada pelo W3C(Word Wide Web Consotium) em 10 de
fevereiro de 1998, porém o projeto da linguagem foi iniciado em meados de 1996, com o
7
objetivo de produzir um mecanismo simples e extensível para representação textual de
informação estruturada e semi-estruturada.
XML é o padrão que começou a permitir o tão desejado ideal de
interoperabilidade aberta. É um dos marcos tecnológico que muitas pessoas discutem e
poucas compreendem completamente [Pulier e Taylor,2007]. A XML leva a uma
interpretação pessoal de acordo com o local aplicado ou na exploração do tópico, sendo
neste contexto apresentado aqui, o mais apropriado afirmar que XML é um conjunto de
padrões que permitem os desenvolvedores alcançarem diversas tarefas [Pulier e Taylor,
2007].
Para ser mais claro, XML é apenas um conjunto de padrões que especificam
como estruturar um documento para ser entendido entre dois computadores ou sistemas,
seu uso tem se tornado muito comum nos dias atuais, seja para definir um website,
compartilhar dados entre dois bancos, enviar resposta de uma requisição, entre outros.
“Em geral, o XML é o novo formato de dados universal. Um formato de dados é
uma convenção para se armazenar ou transmitir dados.” (Pulier e Taylor, 2007).
A figura 2.3 é um exemplo de uma transmissão ou armazenamento de um pedido
usando XML.
Figura 2.3 - Exemplo de um arquivo XML. Fonte [Caetano, 2008]
8
2.4 Web services
Inicialmente, a internet era constituída de páginas com dados ou informação de
forma estática, e consultada somente por pessoas através de programas chamado de
navegador web, também conhecido como browser. Com a evolução da internet e por
necessidade dos usuários as páginas começaram a ter conteúdo dinâmico, proveniente de
banco de dados e outras fontes e também ficaram interativas, com possibilidade do usuário
inserir, alterar ou até excluir informações contidas nas páginas [ABINADER e LINS,
2006].
O navegador web tornou-se o cliente universal da internet, para ser usado por
seres humanos. Este fato provocou o surgimento de várias soluções, no lado servidor, para
a construção de aplicações que sejam capazes de extrair dados de diversas fontes e
disponibilizar para os usuários através do navegador web. Mas só as construções dessas
aplicações não permitiriam uma interoperabilidade e escalabilidade entre sistemas. Para
atender essa necessidade, surgiu os web services.
Um web service é um software, que utilizam um conjunto de padrões abertos para
interoperabilidade, esses padrões permitem a interoperação global de computadores,
independente de plataforma de hardware, sistema operacional, infra-estrutura de rede ou
linguagem de programação.
“Baseados em XML e em tecnologia abertas como WSDL, UDDI e SOAP, web
services apresentam-se como uma das possibilidades para a implementação do
compartilhamento de recursos e a integração entre sistemas corporativos empregando a
internet como meio de comunicação. Suas três principais vantagens estão embasadas no
fato de funcionarem sobre padrões estabelecidos na internet (XML, HTTP, TCP/IP)”.
( Abinader e Lins, 2006).
Comparando web service com a computação distribuída tradicional de troca de
mensagem através de interfaces proprietária, os web services empregam uma interface que
é aceita universalmente, o SOAP, um tipo especifico de XML mostrado na figura 2.4. O
computador solicitante envia uma mensagem SOAP para o computador solicitado
utilizando um protocolo de transporte de mensagem, geralmente o protocolo HTTP. Tendo
em vista que computador solicitante e o computador solicitado entendem SOAP como uma
9
linguagem comum. O computador solicitado consegue entender e processar a requisição e
responde com uma mensagem SOAP. Quando um software está pronto para interoperar
utilizando web services, diz-se que está exposto como web service.
Figura 2.4 – Comunicação web service entre um consumidor e fornecedor usando o
protocolo SOAP. Fonte [PULIER e TAYLOR,2007].
2.5 Os passos para adoção da SOA.
Será apresentado a seguir uma breve visão de dois especialistas em SOA. Como
adotar esta nova metodologia com sucesso e não cometer erros na implementação.
O especialista em SOA Lheureux1 (2007), apresentou na 5ª conferencia anual de
integração empresarial, os passos essenciais para uma implementação bem sucedida de
SOA. Segundo ele são quatros passos importantes: introdução, disseminação, exploração
de resultados e platô [NEXTGENERATION, 2007].
Introdução - É preciso definir um projeto-piloto. A implementação segmentada
reduz os investimentos, permite mostrar as melhorias para alta direção sem ter que
enfrentar o risco de colocar SOA na empresa inteira.
Disseminação - Concluída a primeira fase com sucesso, o desafio é espalhar esse
conceito para as outras áreas, aumentando o escopo de atuação e as pessoas envolvidas.
1 Benoit Lheureux, vice-presidente e analista do Gartner.
10
Exploração de resultado - Qualquer projeto precisa de bons resultados num
prazo razoável. Documentando os benefícios resultantes da implementação, a adoção é
facilitada e cultura é adotada pela empresa.
Platô - Momento em que foi atingido o estado da arte sobre o tema, onde o
conceito pode ser conferido em sua plenitude e aproveitamento na organização.
Segundo Lheureux (2007) o gestor que pular uma das etapas terá o fracasso
garantido.
Atualmente a maioria das empresas está entre a introdução e disseminação do
conceito. Assim, independente do país em que empresa se encontra ninguém está muito
distante em SOA.
Em pesquisa realizada pela IDC2, em Londres, durante a conferência sobre SOA,
60% de um grupo de 140 executivos de TI responderam que ainda estão investigando essa
arquitetura. A pesquisa também mostrou que SOA ainda não foi completamente assimilado
[NEXTGENERATION, 2007].
Segundo Josuttis (2007), em seu livro SOA na prática, ele apresenta um exemplo
também baseado em passos, como: entender, definir um projeto piloto em segundo e o
terceiro e por fim crescer e tornar-se uma estratégia geral.
Entender SOA - O principal objetivo é entender, uma empresa não pode
começar mudar toda sua arquitetura para SOA porque está moda ou porque seu analista de
negócio recomenda ou até mesmo enxergar um beneficio. Segundo ele o benefício nem
sempre é fácil de enxergar, aprender sobre as diferenças entre os sistemas grandes e
pequenos e entre o controle central e distribuído, isto é fundamental.
Além disso, antes de seguir este caminho, é totalmente necessário que o seu
gerenciamento aceite que SOA é uma estratégia, e não uma solução pronta, e também
entender as possíveis conseqüências de implementar esta estratégia, e em especial o que
significa ter processamento distribuídos. No nível gerencial é necessário ter domínio nos
detalhes, controle de versões, e total compreendimento sobre o conceito de acoplamento
fraco [JOSUTTIS, 2007].
Um outro ponto importante segundo Josuttis (2007). SOA não é a solução para
qualquer tipo de integração de sistemas, ao contrário, ela é um conceito para lidar com
2 IDC, empresa de consultoria e conferências nos segmentos de Tecnologia da Informação e Telecomunicações.
11
processos de negócios distribuídos. A replicação de banco de dados e desacoplamento de
front-ends3 e back-ends4 são totalmente diferentes, embora elas possam usar os mesmos
padrões e/ou tecnologias.
Projeto piloto – Neste ponto o objeto é testar SOA, isso significa que a empresa
executa um projeto de teste que tem como objetivo colocar em produção alguma
funcionalidade que inclui alguns processamentos de negócios através de dois ou três
sistemas diferentes. Neste projeto inicial, a empresa concentrará principalmente nas
decisões técnicas e arquiteturais. No entanto, isso deve ser guiado pelas necessidades de
negócio. Isto significa que a equipe que realiza esse piloto deve ser uma mistura de pessoas
de negócio e pessoas de TI [JOSUTTIS, 2007].
No estagio inicial é necessário ter muito cuidado, continua Josuttis (2007), dando
algumas orientações: Use apenas serviços básicos, o que significa iniciar com SOA
fundamental; use apenas um ou dois padrões MEPs5, recomendado começar com padrão
requisição/resposta síncrono ou assíncrono; defina um conjunto mínimo de tipos de dados
fundamentais e construtores de linguagem para agregá-los; escolha uma tecnologia de
middleware6 para o seu ESB; decida sobre a quantidade de acoplamento fraco, ser
conservador neste ponto e ter cuidado com princípio, isto não será necessário; pense sobre
a quantidade de segurança e manutenibilidade que quer prover no momento atual e
momento futuro e por fim sempre pense grande e comece pequeno.
O foco mais importante, além de executar software, deve estar em prover
interfaces excelentes entre o ESB e o negócio. A empresa não tem que decidir aqui sobre
os processos. Primeiro é necessário de software funcionando, depois criar, gerar ou
implementar, isso em um processo de desenvolvimento de software distribuído. Do ponto
de vista de negocio, não se pode começar com um serviço composto ou de processos muito
complexo. O objetivo desta abordagem é fornecer alguma funcionalidade típica de back-
end com a nova infra-estrutura de SOA, talvez vá substituir algum acesso remoto a banco
de dados por um serviço. A funcionalidade implementada deve ter algumas relevâncias
para o negócio. Embora seja provavelmente muito arriscado para ser de missão crítica para
3 Front-ends, é a parte do sistema de software que interage diretamente com o usuário [Wikipedia, 2008].4 Back-ends, é a base de dados e fica por tráz de um front-end [Nogueira, 2008].5 MEPs – Padrão de mensagens requerido em um padrão de protocolos de comunicação[Wikipedia, 2008].6 Middleware – Programa que faz mediação entre outros softwares[Wikipedia, 2008]
12
a empresa, implementar alguma funcionalidade útil necessária vai ajudar a abordagem
SOA a focar em pragmatismo e usabilidade[JOSUTTIS,2007].
O segundo e o terceiro projetos SOA - O segundo e o terceiro projetos são fases
muito importantes na introdução de SOA, nesta fase começa-se pensar sobre todas as
coisas importantes que levam aos efeitos sinérgicos e considerar a reusabilidade dos
serviços. Definir processos para equipes diferentes, encontrar o equilíbrio certo entre
centralização e descentralização e encontrar o ponto certo entre a teoria ou conceitos e a
prática se torna importante.
Segundo Josuttis (2007) à medida que aumenta os números de projetos, o
gerenciamento de multiprojetos deve ser pensado, A Figura 2.5 abaixo demonstra isso em
relação à infra-estrutura comum dos três pilotos. Primeiro projeto piloto cresce com a
infra-estrutura. O segundo e o terceiro projeto pilotos são baseados nas experiências,
decisões e implementações anteriores, mas precisam e adicionar novos recursos que tem
impactos na infra-estrutura geral, causando uma alteração na infra-estrutura inicial. Estas
mudanças não serão apenas adições de novos recursos. A maioria serão atualizações
baseadas em consolidação e generalizações. Interfaces, processos e políticas úteis evoluem
à medida que você as usa e convive com elas. Sempre que um mesmo esforço for repetido
pela terceira vez, será necessário fazer algo para automatizar estes processos conhecido
pela comunidade XP como, Três Strikes, esta automação leva o desenvolvimento orientado
a modelos.
Figura 2.5 – Dependências entre a infra-estrutura e múltiplos projetos. Fonte [JOSUTTIS,
2007].
Otimizar para não fazer as funções repetidamente é uma boa abordagem para
alcançar a excelência. No entanto, observe que o modelo de programação comum em
13
grandes projetos é na abordagem “copiar e colar”. Na SOA é o contrário, para se beneficiar
das melhorias, terá que refatorar os projetos pilotos que já estão em fase terminados, caso
contrário os desenvolvedores irão copiar os códigos e APIs antigas e depreciadas
[JOSUTTIS, 2007].
O padrão “três Strikes” não se aplica apenas aos aspectos de infra-estrutura.
Baseado na figura 2.5 anterior, a palavra infra-estrutura pode ser substituída por processo,
ciclo de vida, políticas, arquitetura entre outras. O importante é entender que o aspecto
SOA sempre está em evolução, o que significa ter os recursos sempre flexíveis para que
sempre que seja necessário modificar as práticas, os códigos existentes e manutenibilidade
para alcançar consistência melhor.
Crescer e tornar-se uma estratégia geral – Para que a empresa tenha a
possibilidade de detectar mais rápido as oportunidades e desafios de negócios, será
necessário gerenciar SOA, gerenciar serviços, contratos de serviços e o monitoramento de
atividades de negócios [JOSUTTIS, 2007].
Para que isso ocorra é crucial neste estágio que a maneira usual de estabelecer
novas funcionalidades de negócios seja completamente descentralizada e automatizada ao
máximo, e para alcançar isso às equipes de serviços centrais terá que ter domínio em suas
funções, isto normalmente requer muitos recursos, mas o importante é não parar o suporte
estratégico de SOA neste ponto.
“Embora com o tamanho aumentado os aspectos de sua estratégia SOA se
tornem mais e mais estáveis, sempre há novos requisitos com que lidar. Eles podem ser
técnicos (Devemos mudar para o novo padrão do protocolo?) ou de negócio (Como
estabelecemos uma conexão B2B que usa um protocolo ligeiramente diferente?). É crucial
aqui que as modificações da plataforma SOA e os processos sejam orientados a negócio.
As infra-estruturas de serviços devem servir às equipes de negócios.” Josuttis (2007).
2.6 SOA no Brasil, como e quando implantar.
A SOA no Brasil ainda está em fase embrionária, sua adoção é muito discutida
por executivos de TI, que precisam entender que é possível começar um projeto dessa
dimensão sem antes instaurar uma política de governança [NEXTGENERATION, 2007].
Alguns especialistas aconselham a começar a implantação pelos processos mais
críticos do negócio e também sugerem que as organizações comecem a implantar SOA aos
14
poucos, orientam que a adoção de novas arquiteturas pode ser feita em etapas, conforme
demandas forem surgindo. Segundo eles o ideal é que as empresas apliquem SOA
inicialmente em processo críticos que exijam mais agilidade, como os sistemas onde a
lógica de negócios possa ser facilmente desagregada da parte de apresentação.
Uma vez que as organizações decidam aderir SOA, elas precisam se certificar de
que os projetos nascerão baseados na arquitetura e quando forem desenhar a arquitetura do
sistema, o responsável pelo projeto deve ter SOA em mente [NEXTGENERATION,2007].
Desde a concepção do sistema, nova arquitetura deve ser levada em consideração.
Alguns dos pesquisadores do SOA no Brasil, segundo a Nextgeneration (2007),
afirmam que durante a implementação do projeto SOA, as equipes identificarão serviços
não muitos utilizados, mas dos quais as empresas também não devem descartar. Com SOA,
algumas funcionalidades serão abstraídas e outras integradas. A arquitetura elimina
retrabalho. As empresas devem construir um catalogo de serviços e utilizá-los para outras
aplicações. Já outros especialistas acreditam que o desafio para a adoção de SOA estão
muito mais do lado organizacional e cultural da empresa, do que em seu aspecto técnico
[NEXTGENERATION,2007].
2.7 Governança em SOA.
Esse tipo governança é focado no ciclo de vida dos processos, serviços,
metadados e na composição das aplicações de uma empresa que utiliza SOA. Governança
SOA define as mudanças da governança de TI para assegurar os conceitos e princípios de
SOA, ou seja, é uma especialização de governança de TI. Pela sua funcionalidade,
governança SOA também provê um framework para examinar diversos itens necessários
para o gerenciamento dos serviços em uma TI, segundo Erl (2005) os principais itens são:
Maturidade dos serviços;
Infra-estrutura para a gerencia dos serviços (segurança, monitoramento,
performance, versionamento e compartilhamento);
Granularidade e reuso dos serviços;
Educação e treinamento;
Regras e responsabilidades;
Mudanças organizacionais.
As atribuições da governança SOA são:
15
Tabela 02 – Outros itens que fazem parte de uma governança SOA, segundo Jones (2006).Registro DesenvolvimentoVersionamento ModelagemProprietário PublicaçãoJunção DiscoveryMonitoramento ReutilizaçãoAuditoria AcessoDiagnóstico ImplementaçãoIdentificação SegurançaConsumo
Tabela traduzida do livro “Enterprise SOA Adoption Strategies” [JONES, 2006].
Um dos principais pesquisadores sobre SOA Josuttis (2007), afirma que governança em SOA é um obrigação e o nível de detalhes e riqueza está totalmente relacionado ao tamanho do projeto em questão.
“Governança da arquitetura orientada a serviço não é uma opção, ela é uma
obrigação. Quanto maior SOA, mais governança ela precisa e mais complexos papéis e
mecanismos da governança devem ser. Os arranjos da governança levam muito tempo
para serem projetados e instalados, mas sem eles, todo projeto SOA fora da fase piloto
esta em risco”. Josuttis (2007).
16
3 Tecnologia Base da SOA.
Como SOA não é uma tecnologia específica a sua implementação, na maioria das
vezes baseada em padrões existente, será apresentado neste tópico as mais comuns e mais
utilizadas nas empresas atualmente.
3.1 Padrões
Os principais benefícios de SOA são claros, como a reutilização dos ativos
existentes, mas o panorama dos padrões ainda não são totalmentes claro. Em um estudo
recente sobre o assunto, segundo Violino (2008), a Forrester Research contabilizou cerca
de 120 padrões flutuando ao redor de SOA e Web services. Descobriu também que é quase
impossível confirmar quais fornecedores suportam quais padrões. Mesmo assim, os CIOs
têm que seguir em frente com projetos SOA para satisfazer as necessidades do negócio
[VIOLINO, 2008]. E também afirma que vários CIOs como, Hong Zhang, diretor e
arquiteto chefe de arquiteturas e padrões de TI da General Motors, tem obtido um
equilíbrio entre o dilema dos padrões e a utilização contínua de SOA, conforme citação
abaixo.
“É bom que existam vários padrões relacionado a SOA, isso indica que a
indústria de software ruma para ampla adoção de SOA, o desafio é não haver uma
framework arquitetural comum, consistente, para orientar a evolução, a integridade e a
intregração destes padrões. Muitos deles ainda não atingiram a maturidade”. Citado por
Violino (2008).
Conforme várias abordagens é trivial afirmar que a maioria das implementações
de SOA nas empresas é utilizando web services [WIKIPEDIA, 2008]. Baseando nisto será
apresentado o padrão de web services mais comum e adotado pelas empresas, conhecido
por pilha de padrões WS-*.
3.1.1 WS-*.
Os web services WS-* surgiram no final da década de 90, quando fabricantes de
midleware perceberam a necessidade de padronizar as implementações de SOA que
estavam surgindo [PEREIRA7,2007]. Isto era o ponto chave para garantir a
7 Bruno Pereira, desenvolvedor Java sênior e líder de equipe da Concrete Solutions.
17
interoperabilidade de aplicações. “Sem a visão de interoperabilidade a metodologia SOA
não faria nenhum sentido” afirma Pereira (2007).
O rápido crescimento dos serviços WS-* se distinguiram pela velocidade das
especificações muito superior à velocidade das aplicações práticas destes padrões. Tais
procedimentos cresceram rapidamente e chegou a um ponto no qual ficou praticamente
impossível acompanhar o ritmo da documentação gerada pelo consórcio de empresa
envolvidas, e isto certamente elevou a complexidade das implementações
[PEREIRA,2007].
O grupo responsável a garantir a interoperabilidade de web services desenvolvida
em diferentes plataformas é o WS-I, este grupo adotou como referência para todas as
implementações da pilha de padrões WS-* da plataforma Java, um conjunto de definições
chamado Basic Profile 1.0. Outra parte importante a respeito à adoção do Basic Profile é
que a Microsoft também adotou estas definições para pilha de SOA .NET8. Partindo deste
princípio o uso deste padrão garanti uma integração bem sucedida entre as duas
plataformas segundo Pereira (2007).
Os web services WS-* tem em sua pilha três padrões importantes que
necessariamente devem ser considerados são eles: WSDL , SOAP e UDDI [ABINADER e
LINS, 2006].
3.1.1.1 WSDLO WSDL tem a função de descrever de modo a preencher lacunas principais
como: informar o consumidor o que o serviço executa como o consumidor pode invocar o
serviço e como o consumidor pode diferenciar serviços similares, oferecidos por diferentes
fornecedores. Com esta descrição, o cliente consumidor interessado em utilizar o web
service, pode fazer de forma automática, sem que seja necessária a intervenção ou contato
como o autor fornecedor do mesmo [PULIER e TAYLOR, 2008].
Partindo para uma visão mais técnica o WSDL é usado para definir as interfaces
dos serviços. Ele pode descrever dois aspectos diferentes de um serviço: Sua assinatura
(nome e parâmetros) e seus detalhes de ligação e deploy (protocolo e localização)
[JOSUTTIS, 2007].
8 .NET, Linguagem de programação da Microsoft.
18
Para um melhor entendimento do WSDL será apresentado na figura 3.1 a
estrutura geral dos arquivos na versão 1.1 e a recém lançada 2.0.
Figura 3.1 – Estrutura geral de arquivo WSDL 1.1 e 2.0. Fonte Josuttis (2007).
Os arquivos WSDL descrevem os serviços de baixo para cima, ou seja, eles
começam com os tipos de dados usados e terminam com o endereço do serviço e contém
três camadas de descrição [JOSUTTIS,2007].
A primeira camada chamada na versão 1.1 de “tipo de porta” descreve a interface
de um serviço e pode consistir uma ou mais operações com parâmetros de entrada e saída
que usam os tipos especificados na primeira seção do arquivo. Na versão 1.1 os
parâmentros de serviços são definidos nas seções <message>, enquanto na versão 2.0 eles
são definidos como qualquer outro tipo na seção <types>.
19
A segunda camada define a “ligação” de um web service, ou seja, o protocolo e o
formato para quais operações de web service são oferecidas.
Já a terceira e ultima camada define a localização física (endereço, URL) onde
web service está disponível.
Para um melhor entendimento serão apresentados na tabela 03 a descrição WSDL
nas duas versões. O WSDL proposto define um serviço de informação de um pedido, onde
o consumidor do serviço informa a um atributo numero do tipo inteiro e tem uma saída de
atributos em formato string: cliente, endereco e float: valorTotalPedido.
Tabela 03 - Descrição de um arquivo WSDL na versão de WSDL 1.1:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="PedidoService"
targetNamespece="http://www.cristaltemper.com.br/wsdl"
xmlns:tns="http://www.cristaltemper.com.br/wsdl"
xmlns:wsd1i="http://www.cristaltemper.com.br/xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap"
xmlns="http://schemas.xmlsoap.org/wsdl">
<types>
<xsd:shema targetNamespace="http://www.cristaltemper.com.br/xsd"
xmlns="http://www.cristaltemper.com.br/xsd">
<xsd:complexType name=”getDadosPedido”>
<<xsd:sequence>
<xsd:element name="pedidoID" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getPedidoResponse" type="DadosPedido"/>
<xsd:complexType name="DadosPedido">
<xsd:sequence>
<xsd:element name="nome" type="xsd:string"/>
<xsd:element name="endereco" type="xsd:string"/>
<xsd:element name="totalValor" type="xsd:float"/>
</xsd:sequence>
20
</xsd:complexType>
</xsd:shema>
</types>
<message name="getDadosPedidoInput">
<part name="params" element="xsd1:getDadosPedido"/>
</message>
<message name="getDadosPedidoOutput">
<part name="params" element="xsd1:getDadosPedidoResponce"/>
</message>
<portType name="PedidoInterface">
<operation name="getDadosPedido">
<input message="tns:getDadosPedidoInput"/>
<output message="tns:getDadosPedidoOutput" />
</operation>
</portType>
<binding name="PedidoSOAPBinding" type="tns:PedidoInterface">
<soap:binding stype="document"
transport="http://shemas.xmlsoap.org/soap/http"/>
<operation name="getDadosPedido">
<soap:operation
soapAction="http://www.cristaltemper.com.br/getDadosPedido" />
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="PedidoService">
21
<port name="PedidoPort" binding="tns:PedidoSOAPBinding">
<soap:address location="http://www.cristaltemper.com.br/pedido11"/>
</port>
</service>
</definitions>Baseado no livro SOA na prática [JOSUTTIS, 2007].
Para uma análise detalhada no arquivo será apresentado por funcionalidade das
seções, percebe-se que os arquivos WSDL descrevem os serviços de baixo para cima e
assim será analisado.
A seção <service> define um serviço chamado de “PedidoService” na URL
http://www.cristaltemper.com.br/pedido11, a qual é fornecida com uma ligação chamada
“PedidoSOAPBinding”. O prefixo tns: é o namespace onde podemos encontrar os detalhes sobre
esse identificador. Ele é definido no inicio do documento e tem o mesmo nome que namespace
target. O PedidoSOAPBinding é um identificador definido neste arquivo.
A seção <binding> define o protocolo e o formato que são utilizados para fornecer os
serviços. Neste local temos a definição de “PedidoSOAPBinding”. No seu inicio já especifica para
qual tipo de interface é a ligação “PedidoInterface”, sem se preocupar com detalhes, a ligação
SOAP utilizando o protocolo http.
A seção <portType> define a interface “PedidoInterface”. Ela versa de uma operação
chamada “getDadosPedido” e especifica as mensagens que serão enviadas através ESB quando
essa operação é chamada. Este serviço e baseado em mensagem de requisição e resposta, com
requisição em “getDadoPedidoInput” e resposta em “getDadoPedidoOutput”.
A seção <message> define mensagens individuais, fazendo uso dos identificadores
referenciados da seção <portType> Tanto o método de requisição e resposta usam um tipo de dados
definido na seção <types>.
A seção <types> define os tipos de dados de entrada e saída.
Tabela 04 - Descrição de um arquivo WSDL na versão 2.0 com SOAP 1.2.
<?xml version="1.0" encoding="UTF-8"?>
<description name="PedidoService"
targetNamespece="http://www.cristaltemper.com.br/wsdl"
xmlns:tns="http://www.cristaltemper.com.br/wsdl"
xmlns:wsd1="http://www.cristaltemper.com.br/xsd"
22
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsoap="http://www.w3.org/2006/01/wsdl/soap"
xmlns:wsdlx="http://www.w3.org/2006/01/wsdl-extensions"
xmlns="http://www.w3.org/2006/01/wsdl">
<types>
<xsd:shema targetNamespace="http://www.cristaltemper.com.br/xsd"
xmlns="http://www.cristaltemper.com.br/xsd">
<xsd:complexType>
<<xsd:sequence>
<xsd:element name="pedidoID" type="xsd:int"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="getPedidoResponse" type="DadosPedido"/>
<xsd:complexType name="DadosPedido">
<xsd:sequence>
<xsd:element name="nome" type="xsd:string"/>
<xsd:element name="endereco" type="xsd:string"/>
<xsd:element name="totalValor" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:shema>
</types>
<interface name= "PedidoInterface">
<operation name="getDadoPedido"
pattern="http://www.w3.org/2006/01/wsdl/in-out"
style = "http://www.w3.org/2006/01/wsdl/style/iri"
wsdlx:safe = "true">
<input messageLabel="In" element="xsd1:getDadosPedido"/>
<output messageLabel="Out" element="xsd1:getDadosPedidoResponse"/>
</operation>
</interface>
<binding name="PedidoSOAPBinding"
23
interface="tns:PedidoInterface"
type="http://www.w3.org/2006/01/wsdl/soap"
wsoap:protocol="http://www.w3.org/2003/05/soap/binding/HTTP">
<operation ref="tns:getDadosPedido"
wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/>
</binding>
<service name="PedidoService" interface="tns:PedidoInterface">
<endpoint name="PedidoEndpoint"
binding ="tns:PedidoSOAPBinding"
address="http://www.cristaltemper.com.br/pedido20"/>
</service>
</escription>Baseado no livro SOA na prática [JOSUTTIS, 2007].
Como demonstrado no arquivo anterior existe algumas diferenças entre elas,
como:
A tag raiz é chamada de <description> diferentemente da versão 1.1 a qual
chamava de <definitions>;
A seção <service> usa “endpoint” e não <port>;
Dentro da seção <binding> definem o protocolo especifico;
A seção <portType> é substituída por <interface>. Ela usa padrões de troca de
mensagens mais específicos, que definem a ordem de baixo para cima;
Usa namespaces diferentes para identificar WSDL 2.0 e SOAP 1.2;
Elimina a seção <message> e as operações passam a referenciar diretamente aos
<types> (tipos de dados).
3.1.1.2 SOAP
SOAP é um protocolo para troca de informações estruturadas em uma plataforma
descentralizada e distribuída, este protocolo e baseado em XML e possibilita a
comunicação efetiva entre sistemas distribuídos estabelecidos sobre conjuntos de software
e hardware heterogêneos.
24
“SOAP é um protocolo projetado para invocar aplicações remotas através de
RPC ou trocas de mensagens, em um ambiente independente de plataforma e linguagem
de programação. SOAP é, portanto um padrão normalmente aceito, para utilizar-se com
Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação
entre diferentes sistemas, através da utilização de uma linguagem (XML) e mecanismo de
transporte (HTTP) padrões” Cunha (2002).
Como a tecnologia deste protocolo é XML, então sua especificação define um
framework que permite construir mensagem que pode trafegar em diversos protocolos
como: http, ftp, smtp, tcp entre outros que foram especificados de forma a ser independente
de qualquer modelo de programação ou outra implementação [WIKIPEDIA, 2008].
Uma das características mais importantes do SOAP é a separação do formato de
dado a ser transmitido, do protocolo de nível inferior que irá transportar o dado,
produzindo independência de plataforma e linguagem, pois utilizam XML como
metadados e outros protocolos bem definidos, como http, para transportar dados pela
internet.
Uma mensagem SOAP consiste basicamente em três elementos, envelope, header
(cabeçalho) e body (corpo), conforme figura 2.7,
Envelope: Deve existir em todas as mensagens. É o elemento raiz do documento
XML. O Envelope pode conter declarações de namespaces e também atributos adicionais
como o que define o estilo de codificação.
Header: Este elemento é opcional. Ele leva informações adicionais, para ajudar a
infra-estrutura a lidar com as mensagens como dica de roteamento, segurança e outros. Se
o cabeçalho header for definido ele deve ser o primeiro elemento do Envelope.
Body: Este elemento é obrigatório e contém o payload, ou a informação a ser
transportada para o seu destino final. O elemento body pode conter um outro elemento
opcional Fault, usado para carregar mensagens de status e erros retornadas pelos nós ao
processarem a mensagem.
25
Figura 3.2 - Estrutura de uma mensagem em SOAP. Fonte Josuttis (2007).
O Processo de uma chamada RPC, antes de serem enviadas pela rede, as
chamadas são encapsuladas ou serializadas segundo o padrão SOAP. O destinatário
servidor, ao receber a mensagem faz o processo contrário, desencapsulando-a e extraindo
as chamadas de método. E na resposta o servidor executa o encapsulamento e encaminha
ao cliente e o mesmo faz o desencapsulamento, veja os exemplos na tabela 05 e 06 a seguir
de um arquivo SOAP.
Tabela 05 - requisição SOAP usando protocolo http.
POST /pedido11 HTTP/1.1
Host: www.cristaltemper.com.br
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: “http://www.cristaltemper.com.br/getDadosPedido”
<?xml version=`1.0`?>
<soap:Envelope xmlns:soap=”schemas.xmlsoap.org/soap/envelope/”>
<soap:Header>
...
</soap:Header>
<soap:Body>
26
<getDadosPedido xmlns= “http://www.cristaltemper.com.br/xsd”>
<pedidoID>454512</pedidoID>
</getDadosPedido>
</soap:Body>
<soap:Envelope>
Tabela 06 - resposta SOAP usando protocolo http.
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<?xml version=`1.0`?>
<soap:Envelope xmlns:soap=”schemas.xmlsoap.org/soap/envelope/”>
<soap:Header>
...
</soap:Header>
<soap:Body>
<dadosPedido>
<nome>Geovane Caetano</nome>
<endereco>Av. do sucesso garantido, 1</endereco>
<totalValor>999.999.999,00</totalValor>
<dadosPedido>
</soap:Body>
<soap:Envelope>
3.1.1.3 UDDI
Como visto até aqui, em um web services baseado em WS-* o padrão SOAP é
responsável pelo transporte das mensagens e o padrão WSDL é responsável pela descrição
dos serviços, ambos são mantidos pela W3C e o padrão UDDI é uma especificação técnica
que tem como objetivo descrever, descobrir e integrar web services e é mantido por um
grupo de empresas do mundo dos negócios. Segundo a OASIS o UDDI é um elemento
central do grupo de padrões que compõe a pilha de componentes dos serviços web
[RECKZIEGEL,2006].
27
Foi inicialmente parte de um termo ainda mais amplo UBR [JOSUTTIS, 2007]. A
idéia original era introduzir todos os três papéis de um mercado em funcionamento:
Fornecedores que oferecem serviço a um consumidor que precisa de um serviço e brokers
que juntam os dois divulgando e localizando os serviços, como na figura 2.8.
Figura 3.3 - Modelo UBR. Broker, fornecedor e consumidor. Fonte Josuttis (2007).
A intenção por trás de UBR era que isso seria o broker central para um mercado
mundial de web services, como se fosse um catálogo telefônico que tem páginas brancas,
amarelas e verdes para que os fornecedores pudessem divulgar seus serviços e os
consumidores localizarem quaisquer serviços desejados, onde:
As páginas brancas: contêm informações sobre nomes, endereços, números de
telefone, além de outras informações sobre os fornecedores do serviço.
As páginas amarelas: contêm listagens comerciais baseadas nos tipos desses
negócios, de maneira organizada por categoria específica ou regiões demográficas.
As páginas verdes: são usadas para indicar os serviços oferecidos por cada
negócio, incluindo todas as informações técnicas envolvidas na interação com o serviço.
Resumindo, explica como fazer a comunicação com eles.
Porém essa idéia inicial não funcionou e foi descartada em 12 de janeiro de 2006,
segundo Josuttis (2007) a IBM, Microsoft e SAP informou que os objetivos do projeto
UBR foram alcançados e seriam descontinuados na data acima.
28
“A falha de UBR não significa necessariamente que UDDI também falhou, mas
há duvida sobre quão importante UDDI é na prática. Parte da razão é que o
gerenciamento de serviços requer um portifólio de serviços significante para ser útil. Mas
outra parte é apenas dever de casa insuficiente”. Josuttis (2007).
29
4 Responsabilidade de um ESB (Barramento de serviço corporativo) em SOA.
Uma das idéias da SOA é disponibilizar serviços que poderão ser utilizados por
outros serviços existentes na empresa. E o service requester (aplicação cliente) não têm a
necessidade de ter nenhum conhecimento da linguagem de programação ou tecnologia
utilizada para implementar o serviço solicitado[MUNDO JAVA, 2007].
Na figura 4.1 mostra uma aplicação, cliente chamando diretamente serviços
disponibilizados em uma aplicação Java com uma stored procedure. Se forem necessários a
criação de um novo serviço em outra linguagem e precisar ser integrado à aplicação, será
necessário escrever mais código para esta integração.
Figura 4.1 – Aplicação chamando serviços sem o uso do ESB. Fonte Mundo Java (2007).
Se o service requester não sabe ou não quer se preocupar sobre as variações como
os serviços do service provider foi implementado e como deve requisitá-lo ou em um
determinado momento queremos abstrair cada um dos serviços existente no service
provider como web service, esta seria a solução. Mas se fossem necessário criar web
services para cada serviço, não seria possível disponibilizar como serviços para que
pudessem ser acessado de qualquer outro lugar.
Neste cenário o ESB resolveria com pouco esforço, conforme a figura 4.2. Um
service requester (aplicação cliente) pode solicitar serviço, implementados de forma
diferente, através de um intermediário que consegue se comunicar com cada uma das
implementações dos serviços necessários.
30
Figura 4.2 – Aplicação cliente chamando serviços pelo ESB. Fonte Mundo Java (2007).
Existem diversas funcionalidades, como: roteamento, segurança, gerenciamento
de transações, orquestração de serviços, coreografia de processos, processamento de
mensagem, mapeamento de serviços, transformações de protocolos, enriquecimento e
transformação de mensagens. Podem ser encontradas em um ESB segundo
Galdino9(2007). Mas nem todos ESBs disponíveis no mercado implementam todas essas
funcionalidades. Dentre elas o mínimo necessário é o roteamento, mapeamento de serviços
e processamento de mensagens [GALDINO,2007], e segundo Silva10 (2008) um ESB deve
prover os recursos como:
Invocação: Para executar funções em serviços assíncronos e síncronos;
Roteamento automático: Para independência de localização dos serviços;
Mediação: Para converter e transformar arquivos (XML, CSV, etc) em dados;
Coreografia de processos: Para executar processos complexos e manter a
integridade das informações;
9 Fernado Galdino é desenvolvedor de projetos J2EE e SOA no Banco JPMorgan10 Edgar A. Silva é Arquiteto da JBoss e desenvolvedor de middleware de missão crítica em SOA.
31
Orquestração de serviços: O que é capacidade de organizar ordens ou
colaborações entre os serviços em busca de um processamento descentralizado, porém
colaborativo para um resultado consolidado e confiável;
Suporte a mensageria: O que é capacidade de processar mensagens e
proporcionar um ambiente reativo a eventos dentro do barramento único;
Serviços adicionais e gerenciamento: Transações, segurança, logging e
auditoria.
Suporte a eventos das aplicações: Como uma transação ou um simples envio de
byte de um protocolo, podem significar um evento que dispara vários serviços numa
corporação.
Um ESB é formado pelos seguintes componentes, conforme figura 4.3.
Figura 4.3 – Componentes de um ESB. Fonte Richard (2008).
O mediator é responsável por funções como roteamento, comunicação,
transformação e enriquecimento de mensagens, e manipulação de erros.
O service registry é responsável por mapear todos os serviços que serão
disponibilizados.
O choreographer é responsável pelo processo de coreografia dos serviços,
gerenciamento das transações e segurança.
32
E rules engine: Pode ser usada em alguns outros componentes para auxiliar no
roteamento, transformações e enriquecimento das mensagens.
4.1 Principais diferenças entre ESBs.
As diferenças entre os ESBs podem ser tecnicamente e conceitualmente. Uma
solução pode não envolver nenhuma ferramenta ou software especifico, em alguns
momentos apenas definir um protocolo pode ser o suficiente. Já outras um ESB pode
reunir diversas ferramentas e programas que rodam de forma centralizada ou
descentralizada e que são utilizadas pelos projetistas, desenvolvedores e operadores dos
serviços.
Para um melhor entendimento serão apresentados diversos tipos de ESB, que
podem ser implementados sistemas específicos.
4.1.1 ESB com conexões ponto-a-ponto e mediação.
Nos ESBs de conexões ponto-a-ponto conforme figura 4.4, os consumidores
devem conhecer previamente o endereço final do fornecedor de serviços. Conhecendo os
endereços do fornecedor, o consumidor envia requisição diretamente para ele. Principal
problema encontrado neste caso é quando o fornecedor estiver inoperante ou inacessível à
chamada simplesmente falha.
33
Figura 4.4 – Exemplo ESB fornecendo conexões ponto-a-ponto. Fonte Josuttis (2008).
Já nos ESB com conexão mediadas, o consumidor não precisa conhecer o
endereço final do fornecedor, ele apenas identifica o serviço por uma tag (etiqueta) ou um
nome simbólico e os ESBs são responsáveis pela localização do fornecedor do serviço,
conforme mostrado na figura 4.5. Como em alguns casos a prioridade e política dos
consumidores não são iguais, estes ESBs podem exercer o papel de um mediador ou broker
deixando esta infra-estrutura fracamente acoplada.
34
Figura 4.5 – Exemplo de conexões mediadas por ESB. Fonte Josuttis (2008).
Um ponto importante desta conexão indireta é que ela pode ter vários
fornecedores de um mesmo tipo de serviço, caso haja necessidade de balancear carga e
tolerância às falhas.
4.1.2 ESB com interceptores.
Uma abordagem deste ESB é substituir o ponto físico final que fornece o serviço
por um hardware ou software para fazer o balanceamento de cargas. Ele também é baseado
no protocolo ponto-a-ponto, porém suporta chamada de serviços indireta, oferecendo os
chamados através de proxies ou interceptores. Os consumidores que desejarem utilizar
estes serviços utilizam um ponto final oficial, que delega a tarefa oficial real, quando as
mensagens chegam, o balanceador de carga demonstrado na figura 4.6, as envia para
diferentes forcenedores de serviços, de acordo com critérios pré-estabelecidos.
35
Figura 4.6 – ESB utilizando um único interceptador para vários fornecedores como
balanceador de cargas. Fonte Josuttis (2008).
Outra abordagem de ESB baseado em interceptadores ou proxy. Diferentemente
da anterior que utiliza apenas uma para vários fornecedores, este utiliza um interceptador
para cada fornecedor, o que o torna bem mais complicado e obriga o consumidor a fazer
conexões ponto-a-ponto apenas com o seu inteceptor específico, conforme figura 4.7. O
inteceptor irá rotear cada chamada para o fornecedor apropriado. Um ponto positivo desta
técnica é que os serviços neste ESB podem ser encapsulados do mundo exterior através dos
interceptores e internamente pode usar diferentes protocolos.
Figura 4.7 – ESB utilizando interceptador para cada fornecedor. Fonte Josuttis (2008).
36
4.1.3 ESB orientado a Protocolo e orientado a API.
Existem duas abordagens diferentes, considerando que a responsabilidade de uma
ESB começa do ponto vista dos consumidores e fornecedores, segundo Josuttis (2008) as
diferenças entre essas abordagens têm um impacto importante sobre os processos de
desenvolvimentos.
Uma das abordagens é o ESB define um protocolo. E os fornecedores e
consumidores devem utilizá-lo para fazer as comunicações, conforme figura 4.8. Este tipo
de ESB é utilizado em web services que requerem o uso do protocolo SOAP.
Figura 4.8 - ESB com conexões orientadas a protocolo. Fonte Josuttis(2008).
Outra abordagem é orientada a API, neste tipo o ESB define as APIs de uma
plataforma ou linguagem de programa, e os fornecedores e consumidores utilizam essas
APIs para implementações e chamada de serviços, conforme figura 4.9.
Figura 4.9 - ESB com conexões orientadas a APIs. Fonte Josuttis(2008).
37
Segundo Josuttis (2008), normalmente a abordagem orientada a protocolo leva a
uma terceira camada do modelo das comunicações distribuídas, demonstrada na figura
4.10. Na parte inferior do modelo existe um protocolo bastante estável, já na parte superior
existe um API para chamar e implementar os serviços. E entre a parte inferior e superior
existe uma camada responsável por fazer a integração.
Figura 4.10 – Camadas do código de negócio até o código de protocolo. Fonte
Josuttis(2008).
É percebido que os protocolos irão mudar ao longo do tempo. Por esta razão, em
algum momento todas as empresas que usam web services, adotam uma camada de
mapeamento, a qual é parte do ESB [JOSUTTIS, 2008].
38
5 Segurança em um ambiente fracamente acoplado.
Mesmo que a comunidade de TI esteja aderindo a SOA por causa da sua
promessa de gerenciamento de TI eficiente e avançada, o problema de segurança tem
contribuído para um avanço mais lento ou até mesmo nenhum avanço em algumas
empresas.
Segundo Pulier e Taylor (2008), segurança sempre foi uma preocupação para os
gestores de TI em grandes companhias. Atualmente grandes e robustos sistemas são
projetados para proteger os dados e informação contra uso não autorizado, intrusão e vírus.
Os web services que praticamente é base de SOA foram desenvolvidos por
consenso da indústria, com o foco em código reutilizável, simplificar o desenvolvimento e
integração entre sistemas. Embora estes objetivos tenham sido alcançados, os padrões
abertos que surgiram não tratam completamente a segurança. Especificamente o XML,
SOAP, WSDL e UDDI são padrões abertos que permitem a transmissão e descrição de
dados, chamadas de procedimento entre sistemas e nenhum deles contem qualquer aspecto
de segurança implementado, sozinhos são totalmente inseguros [PULIER e TAYLOR,
2008].
Partindo de um princípio que os padrões sozinhos são totalmente inseguros, como
é percebida uma tendência natural para adoção da SOA nas empresas, se torna necessário
uma medida de segurança. E quando se fala sobre segurança em sistemas distribuídos,
muitos aspectos devem ser considerados. E as principais categorias como autenticação,
autorização, privacidade, integridade, disponibilidade, contabilização e auditoria devem ser
definidas como os primeiros itens do requisito de segurança.
5.1 Autenticação e autorização.
No modelo de segurança tradicional, a utilização de um firewall ou uma VPN,
evita o acesso de usuários ou sistema não autorizado. Porém, uma SOA demanda que a
arquitetura seja mais flexível e aberta para ser acessada por diversos sistemas para facilitar
a reutilização e o desenvolvimento de novas aplicações, e se o sistema for exposto em web
services mais um ponto inseguro é aberto, pois um harcker pode configurar uma máquina
com serviço semelhante para passar como um fornecedor e realizar chamadas de serviços
errônea e fraudulenta [PULIER e TAYLOR, 2008], conforme exemplificado na figura 5.1.
39
Figura 5.1 – Modelo de segurança em uma aplicação tradicional com firewall e web
service sem segurança. Fonte Pulier e Taylor(2008).
Para resolver este problema imposto é necessário criar uma autenticação para
verificar a identidade de quem está chamando o serviço, se a identidade for válida cabe ao
método de autorização verificar quais tipos de serviços e resposta o consumidor tem
acesso.
5.2 Privacidade e integridade.
A privacidade de dados é manter os mesmos confidenciais enquanto estiver em
trânsito ou em armazenamento. Na ótica de serviço isso significa garantir que ninguém que
não seja o consumidor tenha acesso de visualização aos dados enquanto estiver trafegando
entre o fornecedor e o consumidor. Já a integridade é a garantia de que os dados não sejam
manipulados ou falsificados; um dos fatores mais importante em um TI. Uma infra-
estrutura que não pode garantir um alto nível de privacidade e integridade não é
considerada segura.
Em uma SOA com um nível inadequado de privacidade e integridade, um hacker
através de uma máquina não autorizada poderá interceptar mensagem SOAP em tráfego e
40
espionar ou alterar com propósito de fraude ou maliciosamente [PULIER e TAYLOR,
2008], como mostrada na figura 5.2.
Figura 5.2 – Interceptação, roteamento e modificação das mensagens SOAP por um
Hacker ou pessoa não autorizada. Fonte Pulier e Taylor(2008).
Este cenário mostra claramente a necessidade de criptografar às mensagens
SOAP entre os sistemas.
5.3 Inundação.
Uma SOA não-segura e aberta para todos, usuários mal intencionados ou
maliciosos, mesmo sem autorização para usar o serviço, pode usar alguma técnica para
gerar inúmeras requisições forçando o serviço a ficar inoperante. Este ataque é conhecido
como DoS(negação de serviço) o seu principal objetivo é de impedir que usuário legítimo
utilize um determinado tipo serviço, devido a sobrecarga no sistema em atender as
requisições falsas, demonstrada na figura 5.3.
41
Figura 5.3 – Inundação com requisição ao serviço em uma SOA não segura. Fonte. Pulier
e Taylor (2008).
Um fator que torna o DoS um risco muito sério é a falta de capacidade da SOA
não-segura de monitorar ou garantir os níveis e desempenhos dos serviços de seus web
services pois se um hacker atacar, ela não possui nenhuma maneira inerente de dizer que
está sobrecarregada e nem permite aos administradores do sistema identificar e responder a
problemas de segurança rapidamente [PULIER e TAYLOR, 2008].
5.4 Auditoria
O objetivo é avaliar um conceito de segurança de uma aplicação e melhorar a sua
confiabilidade. Auditoria pode ser definida em gravar todas as informações relevantes à
segurança para que em uma análise futura possa detectar falhas e possíveis ataques, como
parte de uma auditoria em sistemas inclui monitorar e guardas logs e rastrear fluxo de
dados que são relevantes. Auditoria em algum momento pode ser um componente
funcional, quando um permite manipulação e alteração de dados [PULIER e TAYLOR,
2008].
“Um log de auditoria é uma ferramenta fundamental de segurança de TI. Para
examinar o desempenho de segurança de diagnosticar problemas de segurança, os
profissionais de ter acesso a logs acurados de comportamentos dos sistemas.” Pulier e
Taylor (2008).
42
6 Estudo de caso baseado em grandes empresas que implementaram SOA.
No início da SOA a meta de muitas empresas era simplesmente
disponibilizar funcionalidade de aplicações com serviços compartilhados. Mas nos últimos
dois anos o lado do negócio adquiriu melhor percepção do valor estratégico de TI, e a TI
aprendeu mais sobre as pressões competitivas que o negócio tem de suportar,
conseqüentemente a SOA proporciona uma melhor e um maior alinhamento entre TI e
negócio [GRUMAN, 2007].
O negócio precisa de um conjunto de serviços que possa ser reagrupado, que
resulta um novo processo de negocio que suporta novos produtos ou serviços. E SOA
permite publicar estes serviços e frameworks coerentes para que eles possam ser
governados e compostos em aplicações.
Para uma análise e estudo de caso será apresentado algumas possíveis
maneiras de implementar SOA baseando em empresas que aceitaram a divulgação de seus
processos e metodologia pelo pesquisador Gruman(2007) na revista CIO, estas empresas
são: Comcast; Leapflog Enterprise ; United Airline; Thoman Financial e Jabil Circuit.
6.1 Comcast
Quando uma empresa decide adotar a abordagem SOA, é tentador começar a
comprar uma ESB (Barramento de serviço empresarial), registros e outras ferramentas.
Mas o principal valor da SOA é esquecido ou colocado de lado como: o alinhamento entre
as aplicações que são criadas e implementadas e os processos de negócio que elas
executam, segundo Adler11 citado por Gruman(2007).
Começar com a arquitetura pode ajudar a garantir que tem o framework certo
para isso – agora e à medida que as necessidades mudam, com o correr do tempo, segundo
Gruman(2007).
“Quando iniciamos esta empreitada, 18 meses atrás, resistimos à tentação de
trazer fornecedores. Trouxemos especialista em determinados assuntos e descobrimos do
que precisamos em primeiro lugar, todos os fornecedores só queriam nos vender um ESB”
Adler citado por Gruman (2007).
Segundo Gruman (2007) a arquitetura SOA vai além de estabelecer framework,
ela tem o papel importante em identificar onde existe redundância de processos de negócio
11 Tom Adler é gerente sênior de arquitetura de aplicações e governança de TI da Comcast.
43
e aplicações. Isso torna fundamental para explicar o motivo da adesão dessa arquitetura em
termos reais e justificar o investimento em infra-estrutura e ferramentas SOA.
O primeiro passo da Comcast foi desenvolver a arquitetura, como modelo de
domínio comum, o próximo passo foi desenvolver o framework de governança para
criação e a implementação de serviço. Somente os serviços que passam pelos requisitos da
governança são acrescentados ao registro de serviços e disponibilizados para reutilização,
isto permite mostrar a existência de um serviço e guia para uma adoção certa das políticas
e procedimentos.
Após a implantação Adler, citado por Gruman (2007), percebeu e afirma que a
Comcast deveria ter desenvolvido um modelo de serviço de dados comum depois de
definir a arquitetura. Sem serviços de dados padrões para acessar informação corporativa e
gerenciar interações entre sistemas, os desenvolvedores acabaram projetando seus serviços
para executar o trabalho de diferentes maneiras. O que geraram inconsistências, quebrando
a promessa de SOA de possibilitar uma mix fácil de componentes de serviços. E o preço
disso foi, posteriormente, ter que refazer alguns serviços para impor este modelo.
“O foco arquitetural da iniciativa SOA da Comcast ajudou a aplicar o conceito
mais amplamente do que se ele fosse visto apenas como uma questão tecnológica. A
Comcast não partiu da visão de que SOA significa usar web serviçes e aplicou o conceito
SOA a todos os seus esforços, não apenas aos que eram claramente capacitado para web.
Um web service é simplesmente mais uma maneira de expor um serviço, um detalhe de
implementação.” Adler citado por Gruman (2007).
Segundo Gruman (2007) a empresa tem que adaptar a necessidade de negócios
que mudam e as oportunidades tecnológicas. É importante rever a arquitetura de referência
constantemente para que ela não se transforme em uma camisa-de-força ou simplesmente
em um documento que todos ignoram; em qualquer um dos casos a empresa perderia os
benefícios de SOA. Um período sugerido é uma vistoria mensalmente, mesmo não fazendo
nenhuma alteração neste período.
44
6.2 Leapfrog Enterprise.
O problema das aplicações desenvolvidas por grupo desenvolvedores de TI
diferentes atingiu a Leapfrog Enterprise no início de 2007 quando tentou trazer para um
sistema comum em um portal web, solicitado por um fabricante de brinquedos educativos a
disponibilizar suas diversas aplicações para fornecedores e clientes de uma maneira
consistente, com o objetivo de melhor se beneficiar do comércio e das transações na
internet. A Leapfrog não viu alternativa e decidiu que precisava de uma nova maneira de
desenvolver aplicações, partiu para uma iniciativa SOA que está começando dar bons
frutos, segundo Ciurana12 citado por Gruman (2007).
A Leapfrog tinha muitos objetivos comuns a uma típica iniciativa SOA, queria
uma maior reutilização de código, desenvolvimento mais veloz e integração mais fácil.
Mas a empresa não queria limitar a iniciativa SOA uma mudança da guarda de ferramentas
de desenvolvimento e plataformas de integração.
Ao contrário a Leapfrog queria dispensar seus desenvolvedores de se submeter à
idéia de melhores práticas de uma plataforma, mas queria que os mesmos focassem na
funcionalidade das aplicações e utilizassem a melhor e mais adequada tecnologia para cada
trabalho. Atualmente os desenvolvedores da Leapfrog utiliza uma miscelânea de Java 5 e 6
, C# e web service com diversas bibliotecas de terceiros.
Segundo Gruman (2007), Ciurana também não quis obrigar os desenvolvedores a
usar o mesmo transporte, segundo ele o tipo de transporte não importava. Ele optou pelo
open source ESB Mule como backbone de mensagem, apoiando-se nele para lidar como
interfaces de transporte, Assim os desenvolvedores poderiam enfocar o mínimo possível a
implementação de serviços, o foco principal e funcionalidade.
Os desenvolvedores tendem a usar http e alguns empregam SOAP como
mecanismo de transporte, baseando-se no que funciona melhor ou que é mais cômodo. E
com uso do ESB Mule, eles não precisam se preocupar como o que há em uma pilha de
SOAP específica e qual IDE estão utilizando.
A empresa pôde adotar esta abordagem por causa do foco em integrar aplicações
observa, Ciurana.
12 Eugene Ciurana é diretor de infra-estrutura de sistemas da Leapfrog
45
“A maior parte da integração está acontecendo no nivel da aplicação, ou seja,
aplicações se comunicando com outras aplicações, portanto, aplicações fazem inputs e
outputs”. Ciurana citado por Gruman (2007).
A simplicidade do ESB Mule e o uso com sucesso dele em projetos anteriores na
walmart.com foi ponto positivo para adoção na Leapfrog e também pelo motivo da única
tarefa neste ESB que é gerenciar mensagem [GRUMAN, 2007].
Segudo Ciurana a leapfrog utiliza dois ESBs, uma para gerenciar fluxo de dados e
handoffs de aplicações em sistemas internos com ERP, ActiveDirectory e data
warehousing, e outro para aplicações de contato com o cliente baseadas na web, como a
aplicação de autogerenciamento de contas dos clientes e os games on-line que oferece aos
clientes [GRUMAN, 2007]. Isso não só traz um limite natural para gerenciamento de
segurança e acesso, como também provê capacidade mutua de backup, já que cada ESB
pode assumir no lugar do outro, se necessário.
A leapfrog teve que criar um esquema comum de nomeação de serviço para que
os serviços pudessem executar em ambos ESBs, mas isso é um pequeno preço a pagar pela
liberdade do ESB, diz Ciurana [GRUMAN,2007].
6.3 United Arline
As premissas básicas de SOA requer que as funções transacionais distintas sejam
construídas em blocos, para que possam ser recombinadas quantas vezes for necessária.
Entretanto, muitas tarefas de negócio não são tão passíveis de decomposição, apoiando-se
em seqüências especificas de eventos.
“As companhias aéreas são um exemplo clássico de conjunto de processos
baseado em eventos e, normalmente, têm uma arquitetura baseada em eventos(EDA) para
lidar com eventos. EDA é muita orientada para fluxos, enquanto SOA tem a ver com
caixas preta distintas, mas as duas arquiteturas têm seu lugar” Cidambi13 citado por
Gruman (2007).
As companhias aéreas possuem sistemas de transação, como reservar passagens e
marcar assentos, não apenas sistemas baseados em eventos, como despachar caminhões de
combustível quando um avião aterrissa ou atualizar o painel de aviso de chegadas de vôos.
13 Ramnath Cidambi é gerente de engenharia de middleware da United Airlines
46
A United investiu há tempos em EDA, usando o WebSphere da IBM como
barramento de mensagem por sete anos. Em 2006, deu início a uma implementação SOA
para lidar com os web services modernos usados no web site united.com. Entretanto estes
dois ambientes são bastantes diferentes e existiam paralelamente [GRUMAN,2007].
“Mas isso está começando a mudar à medida que a empresa agrega serviços de
transações às suas operações internas, por exemplo, informar aos representantes de
serviços ao cliente através de mensagens de texto (usando web services) qual é o
cronograma do dia, empregar sistemas de RH para ver que está agendado e quem avisou
que está doente, e assim por diante, de forma a designar os funcionários para os diversos
portões de cada aeroporto. Isso coloca web services nos mesmos ambientes que os
processos baseados em eventos, fazendo com que a companhia aérea inicie uma
implementação SOA para além do programa united.com.” Cidambi citado por Gruman
(2007).
O desafio da United é projetar e implementar serviços na companhia sabendo que
a mesma possui e necessita das duas arquiteturas e podendo tratar como entidade distintas.
Exemplo um vôo cancelado (um evento) também tem implicações para os sistemas de
transação (remarcar vôos de passageiros, atualizarem ferramentas de pesquisas de status de
vôos na web ou emitir vouchers de créditos). Muitos processos têm um componente de
evento e um componente de transação: os representantes de serviços ao cliente, obtêm a
programação do dia em sistema de transação, mas mudanças de status de aviões devido o
cancelamento, atrasos por condições climáticas e coisas do gênero tornam essas
programações confusas muito rapidamente, sendo assim o sistema baseado em eventos
rastreia os status dos aviões e o sistema de transação de programação atualiza as
atribuições da equipe ao consultar este status periodicamente e os monitores de exibição
dos horários de vôos empregam o mesmo processo [GRUMAN,2007]. Já o sistema de
mensagem foi o maior desafio, os ESBs não utilizam padrões fora dos padrões web
services, afirma Cidambi citador por Gruman (2007). O modo de lidar com serviços
baseados em eventos são obscuros e varia conforme o produto ou ferramenta. Mas
Cidambi valoriza o uso de ESBs para SOA e EDA porque eles lidam com mensagem,
transformações de dados e outras tarefas criticas de roteamento de dados.
47
Atualmente a United usa dois ESBs, um para EDA e um para SOA, e também a
companhia decidiu usar um broker de integração IBM webSphere como plataforma de
mensagem orientada para publicação/assinatura para serviços baseado em eventos,
programando eventos conforme o necessários e suportando quaisquer transformações entre
serviços, essencialmente atuando como um ESB EDA. Para o transporte foram escolhidas
as aplicações J2EE existentes que são bastante orientadas a mensagem. E todas JMS como
padrão de mensagem ao invés de web services.
Para serviços SOA, a United está adotando o ESB BEA Aqualogic, por acreditar
que uma plataforma mais nova será mais orientada ao conceito moderno de SOA e mais
adequada ao ambiente servidor WebLogic e também para evitar esforço com integração, já
que o Aqualogic roda sobre o WebLogic e a IDE eclipse, explica Cidambi.
Outra dificuldade que Cidambi enfrenta é a falta de esquemas XML padrões para
EDA, fazendo com que a transferência de mensagens entre serviços EDA e SOA seja mais
complexa e demande um número maior de desenvolvedores.
6.4 Thomson Financial
Muitas empresa pensam em implementar SOA porque ela promete deixar o
desenvolvimento mais rápido. Mas alguns desenvolvedores descobriram que um elemento
chave da govenança de serviço, na realidade pode tornar mais lento o desenvolvimento,
tirando a velocidade prometida, segundo Miteski citado por Gruman (2007).
“Para ser considerado um de produção empresarial, um serviço precisa estar
em conformidade com diversas metodologias e políticas, muitas são bastante rígidas: os
nomes de elementos XML não podem ser abreviados e têm que ser palavras de
dicionários, por exemplo. Alguns itens, como nomes e senhas de usuários, não podem ser
hard-coded”. Miteski citado por Gruman(2007).
A Thomson Financial tem milhares de serviços com alta granularidade e baixa
granularidade e tudo que pode haver entre os dois e uma pequenas equipe de arquitetura,
sentiu o golpe rapidamente, porque não importa a granularidade, todo serviço passa por
este processo, só então ele é entrado no registro de serviços. Da mesma forma, a
conformidade de serviços alterados tem que ser avaliada antes que a nova versão seja
48
registrada e disponibilizada para uso em produção, sendo assim o departamento de
arquitetura da financial esta constantemente em gargalo [GRUMAN,2007].
“Reduzir os requitos de compliance não era uma opção, dada à natureza critica
das aplicações envolvidas, como os serviços de single sign-on, web services que fornecem
informações sobre o mercado financeiro para analistas e empresas, e serviços de analises
e graficos financeiros baseados na web e acessados através do Microsoft Office.” Miteski
citado por Gruman (2007).
A solução da Thomson para o problema de workload de conformidade era
recorrer à automação, utilizando ferramentas de avaliação de políticas da weblayer.
Segundo Mitevski, as ferramentas são mais eficientes e não deixam passar violações.
Levou algum tempo para criar as políticas nas quais as ferramentas se baseiam para avaliar
a conformidade e é vital que os arquitetos examinem as analises das ferramentas para ver
se determinados problemas surgem repetidamente, indicando falta de entendimento de
políticas-chaves por parte dos desenvolvedores ou ambigüidade na arquitetura, observa
Mitevski, esta metodologia ajuda a mostrar o que pode ser feito melhor, e quais políticas
precisam ser ajustada.
Mitevski descobriu que a maioria das violações acontecem porque os
desenvolvedores tomam atalhos. Os arquitetos também decidem quando abrir exceções aos
desenvolvedores por qualquer violação à conformidade, algo que acontece raramente. As
exceções são anotadas no registro para conhecimento de outros usuários.
Na Thomson Financial, os resultados da automação de conformidade dos serviços
são surpreendentes. Segundo Mitevski, antes para colocar um serviço em atividade, eram
necessárias 20 pessoas em um processo altamente orquestrado em vários grupos. Agora
uma pessoa é o suficiente, comemora Mitevski [GRUMAN,2007].
6.5 Jabil Circuit.
Uma empresa focada em serviços de manufatura tem que enfrentar uma grande
empreitada de integração do cliente, por exemplo, sistemas de billing, previsão e entrada
de pedidos e os muitos sistemas utilizados por seus clientes. Mas é muito difícil gerenciar
toda esta comunicação ponto-a-ponto à medida que a base de clientes crescem e evoluem
os próprios sistemas. Devido a esta evolução muitos fabricantes migraram para
fornecedores de hubs de transações, conhecido como VANs. Cada fornecedor e cliente se
49
preocupam apenas com uma conexão com a VAN, e para cada dupla cliente-fornecedor
Gilvin14 [GRUMAN,2007].
“Mas esta abordagem fracassa quando você tem processos personalizados junto
aos seus clientes que não são suportados por VANs padrões. A jabil Circuit, fabricante de
produtos eletrônicos personalizados, enfrentou este dilema da maneira mais difícil:
manter manualmente todas as interfaces e aplicações personalizadas.” Gilvin citado por
Gruman (2007).
A Jabil tem mais de cinco mil parceiros comerciais e era possível lidar com a
maioria deles através da abordagem de VAN. Mas 50 clientes precisam de mecanismos de
comunicação ou processo de negócio especial para os quais a Sterling Commerce VAN
havia sido projetada. Com freqüência, havia várias destas conexões personalizadas para
cada cliente, aumentando o esforço e algumas precisam mudar, lembra Gilvin.
Baseado nestes altos esforços, então a Jabil adotou o princípio SOA para
substituir a maioria destas conexões personalizadas por conexões baseadas em serviços que
possibilitam a reutilização de funções comuns.
O primeiro passo foi separar os processos de negócio, gerenciamento do pedido
até o pagamento, previsão e estoque em consignação. Por exemplo: os processos de
comunicação. A Jabil agora tem serviços padrões para a maioria dos mecanismos de
comunicação em uso, como AS1, AS2 e FTP, e serviços separados de tratamento de dados,
para os formatos XML, flat-file, Excel e SAP iDocs [GRUMAN,2007].
A empresa compõe o serviço de comunicação, o serviço de tratamento de dados e
o serviço de negócio apropriado para cada um destes clientes, usando tabelas e metadados
para automatizar a composição na maioria dos casos. Em alguns casos, os clientes utilizam
mais de um mecanismo, talvez de acordo com o departamento em questão, e as tabelas dão
conta destes múltiplos mecanismos, diz Gilvin.
Em alguns casos, requisitos especiais não podem ser satisfeitos através da
combinação de serviços. Portanto, a Jabil ainda tem algumas integrações one-off para
manter. Más, portanto, a empresa pode usar a abordagem SOA para parte da integração. Os
certificados para validação de XML e SSL, por exemplo, não podem ser tratados como
serviços padrões, mas a Jabil pode compor os serviços de comunicação e negócio
apropriados com um serviço de tratamento de dados hard-wired, mantendo os benefícios
14 Lowel Gilvin é gerente de comércio eletrônico da empresa Jabil Circuit.
50
de reutilização e consistência de SOA em dois dos três aspectos da integração, segundo
Gilvin.
Segundo Gilvin, no gerenciamento das mensagens o ESB foi substituído por um
registro para gerenciar o repositório de serviços ou um ambiente de desenvolvimento
orientado a SOA para desenvolver os serviços, a Jabil emprega o Gentran Intregation Suíte
da Sterling Commerce para as três finalidades. O pacote foi projetado para interações do
supply-chain, justamente o que a empresa esta tentando gerenciar. Este escopo limitado
permite que a Jabil se apóie na arquitetura embutida do conjunto de ferramentas, ao
contrario de criar a sua própria e com isso diminuiu o conjunto de processos padrões.
[GRUMAN,2007].
51
7 Conclusão.
O conteúdo deste trabalho deixa transparente que SOA não é uma invenção, mas
sim um paradigma que junta os conceitos e as práticas existentes. É possível dizer que
SOA é a junção da capacidade intelectual mais o pragmatismo dos sistemas distribuídos e
que as pessoas claramente tem o papel de grande importância, pois são elas que fazem o
com que os processos de negócios, os investimentos acertados aliado à ousadia e coragem,
proporcionarem resultados, retorno sobre investimento em uma corporação ou empresa.
Sendo assim, muito antes de falar de tecnologia, SOA deve ser visualizado como um
processo de modernização, onde a empresa deve possuir uma base sólida para suportar as
mudanças exigidas pelo mercado.
Como em todas outras mudanças, SOA também não é diferente. Não se pode
apenas visualizar os benefícios para sua implementação e adoção, é necessário um bom
estudo de caso, um levantamento de requisito preciso e uma boa análise e escolha do
projeto piloto para dar um inicio ao projeto.
52
Bibliografia
ABINADER, J.A.; LINS, R. D. Web Services em Java. Rio de Janeiro: Brasport, 2006.
CESAR, R. Cresce o Lego do Software. In: Portal Exame. 2006. (http://info.abril.com.br/aberto/infonews/082006/01082006-12.shl), data da ultima consulta mai. 2008.
CUNHA, D. Web Services, SOAP e Aplicações Web. In: Site Netscape Devedge. 2002. (http://devedge-temp.mozilla.org/viewsource/2002/soap -overview/index_pt_br.html) data da última consulta mai. 2008.
ERL, T. Service Oriented Architecture: concepts, techology and design. California: Pearson Education, 2005.
GRUMAN G. Cinco maneiras de implementer SOA. In: Portal UOL. 2007. (http://cio.uol.com.br/estrategias/2007/11/12/idgnoticia.2007-11-12.0220762598/), data da última consulta mar. 2008.
JAVA MAZINE. Rest vs WS-*. Grajaú: Devmedia Group, n. 54, p.38-47, 2007.
JAVA MAZINE. JBoss ESB, Trazendo SOA com elegância para as empresas. Grajaú: Devmedia Group, n. 59, p. 44-53, 2008.
JONES, S. Enterprise SOA Adoption Strategies: using SOA to deliver it to the business. Toronto: C4Media, 2006.
JOSUTTIS, N. M. SOA na Prática: a arte da modelagem de sistemas distribuídos. Jacaré: Alta Books, 2008. MUNDO JAVA. Tendências em foco. Rio de Janeiro: Editora Mundo, n. 26, p. 74, 2007.
NEXTGENERATION. Curso SOA. In: Portal Nextg. 2007. (http://www.nextg.com.br/v3/web/curso.php?curso_id=52&modulo_id=426) data da última consulta dez. 2007.
NOGUEIRA, K. Back-end. In: Fórum Access.2008 (http://forumaccess.com/eve/forums/a/tpc/f/449606231/m/100609431) data da última consulta jun.2008.
PULIER, Eric; TAYLOR, Hugh. Compreendendo SOA Corporativa. Rio de Janeiro: Editora Ciência Moderna, 2008.
RECKZIEGEL, M. Descrevendo, descobrindo e Integrando Web Services. In: Portal Imaster. (http://www.imasters.com.br/artigo/4474/webservices/descrevendo_descobrindo_e_integrando_web_services_-_uddi/) data da última consulta abr. 2008.
53
RICHARD, W. M. The Hole of Enterprise Service Bus. In: Portal Infoq. (http://www.infoq.com/resource/presentations/Enterprise-Service-Bus/en/slides/slide0.swf) data da última consulta ago. 2008.
WIKIPEDIA. Front-end. In: A enciclopédia Livre. 2008. (http://pt.wikipedia.org/wiki/Front-end) data da última consulta jun. 2008.
WIKIPEDIA. Middleware. In: A enciclopédia Livre. 2008. (http://pt.wikipedia.org/wiki/middleware) data da última consulta jun. 2008.
WIKIPEDIA. Message Exchange Pattern. In: Wikipedia the Free Ecyclopedia. 2008 (http://en.wikipedia.org/wiki/Message_Exchange_Pattern) data da última consulta jun. 2008.
WIKIPEDIA. Service oriented architecture. In: Wikipedia the Free Ecyclopedia. 2008 (http://pt.wikipedia.org/wiki/Service-oriented_architecture) data da última consulta jun. 2008.
WIKIPEDIA. Soap. In: Wikipedia the Free Ecyclopedia. 2008 (http://pt.wikipedia.org/wiki/SOAP) data da última consulta jun. 2008.
VIOLINO, B. Como navegar no mar de padrões SOA. In: Portal UOL. 2008. (http://cio.uol.com.br/gestao/2008/01/09/idgnoticia.2008-01-09.3145720442/) data da última consulta ago. 2008.
54