UNIVERSIDADE FEDERAL DE VIOSA

CENTRO DE CINCIAS EXATAS E TECNOLCIAS

DEPARTAMENTO DE INFORMTICA

ARQUITETURA ORIENTADA A SERVIO: MAIOR INTERAO ENTRE

ESTRATGIA DE NEGCIO E A TECNOLOGIA DA INFORMAO.

GEOVANE FRANCISCO CAETANO

VIOSA
MINAS GERAIS BRASIL
2008

GEOVANE FRANCISCO CAETANO

ARQUITETURA ORIENTADA A SERVIO: MAIOR INTERAO ENTRE

ESTRATGIA DE NEGCIO E A TECNOLOGIA DA INFORMAO.

Monografia

apresentada

ao

Departamento de Informtica, como parte das

exigncias do curso de Ps-Graduao Lato
Sensu

em

Cincia

da

Computao,

da

Universidade Federal de Viosa.

ORIENTADOR
Mauro Nacif Rocha

VIOSA
MINAS GERAIS BRASIL
2008
I

GEOVANE FRANCISCO CAETANO

ARQUITETURA ORIENTADA A SERVIO: MAIOR INTERAO ENTRE

ESTRATGIA DE NEGCIO E A TECNOLOGIA DA INFORMAO.

APROVADA EM____/____/______

PROF.
JOS LUIZ BRAGA
PROF.
JUGURTA LISBOA FILHO

PROF. MAURO NACIF ROCHA INF/UFV

(ORIENTADOR)

VIOSA
MINAS GERAIS BRASIL
2008
II

AGRADECIMENTOS

Agradeo primeiramente a Deus pela paz, sade e pela fora concedida nesta
caminhada e conquista.
E claro que no posso prosseguir sem agradecer minha famlia e amigos que
sempre me apoiaram e estenderam suas mos nos momentos necessrios.
Sou especialmente grato a minha noiva Nair Alves pela compreenso, carinho e
energia positiva que pacientemente aceitou minha ausncia nos ltimos meses enquanto
estava ocupado trabalhando neste projeto.
Tambm no posso esquecer de agradecer meus colegas de trabalho que
diretamente ou indiretamente esto contribuindo para que este projeto seja concludo com
xito.
E os meus sinceros agradecimentos ao orientador, Mauro Nacif, pelo apoio,
dedicao e interesse neste estudo e desenvolvimento deste tema. E a todos os professores
do departamento de informtica da UFV, que no mediram esforos para contribuir na
minha especializao e formao profissional.

III

SUMRIO
LISTA DE FIGURAS....................................................................................................... VI
LISTA DE TABELAS..................................................................................................... VII
LISTAS DE ACRNIMOS E SIGLAS......................................................................... VIII
RESUMO.......................................................................................................................... X
1. INTRODUO............................................................................................................. 1
2. Viso Geral da SOA..................................................................................................... 3
2.1. Definio............................................................................................................... 3
2.2. Conceito de SOA................................................................................................... 4
2.2.1.Viso o que servio...................................................................................... 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 adoo da SOA..............................................................................10
2.6. SOA no Brasil, como e quando implantar.............................................................14
2.7. Governana em SOA............................................................................................. 15
3. Tecnologia Base da SOA.............................................................................................. 17
3.1. Padres.................................................................................................................. 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 servio corporativo) em SOA.............30
4.1. Principais diferenas entre ESBs........................................................................... 33
4.1.1.ESB com conexes ponto-a-ponto e mediao.............................................. 33
4.1.2.ESB com interceptores...................................................................................35
4.1.3.ESB orientado a protocolo e orientado a API................................................ 37
5. Segurana em um ambiente fracamente acoplado........................................................ 39
5.1. Autenticao e autorizao.................................................................................... 39
5.2. Privacidade e integridade....................................................................................... 40
IV

5.3. Inundao...............................................................................................................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. Concluso..................................................................................................................... 52
Bibliografia......................................................................................................................... 53

LISTA DE FIGURAS
Figura 1.1 - Conexes para integrao em um sistema no SOA..........................................1
Figura 2.1 - Processo de Faturamento usando vrios servios.............................................. 4
Figura 2.2 - Interoperabilidade usando interface em EAI..................................................... 6
Figura 2.3 - Exemplo de um arquivo XML...........................................................................8
Figura 2.4 - Comunicao web service entre um consumidor e fornecedor usando o
protocolo SOAP...................................................................................................................10
Figura 2.5 - Dependncias entre a infra-estrutura e mltiplos 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 Aplicao chamando servios sem o uso do ESB........................................... 30
Figura 4.2 Aplicao cliente chamando servios pelo ESB............................................. 31
Figura 4.3 Componentes de um ESB................................................................................32
Figura 4.4 Exemplo ESB fornecendo conexes ponto-a-ponto........................................34
Figura 4.5 Exemplo de conexes mediadas por ESB....................................................... 35
Figura 4.6 ESB utilizando um nico interceptador para vrios fornecedores como
balanceador de cargas.......................................................................................................... 36
Figura 4.7 ESB utilizando interceptador para cada fornecedor........................................ 36
Figura 4.8 - ESB com conexes orientadas a protocolo...................................................... 37
Figura 4.9 - ESB com conexes orientadas a APIs............................................................. 37
Figura 4.10 Camadas do cdigo de negcio at o cdigo de protocolo............................38
Figura 5.1 Modelo de segurana em uma aplicao tradicional com firewall e web
service sem segurana.......................................................................................................... 40
Figura 5.2 Interceptao, roteamento e modificao das mensagens SOAP por um
Hacker ou pessoa no autorizada......................................................................................... 41
Figura 5.3 Inundao com requisio ao servio em uma SOA no segura.....................42

VI

LISTA DE TABELAS
Tabela 01 Assuntos tpico a ser considerado na implementao do acoplamento fraco em
um sistema............................................................................................................................. 7
Tabela 02 Outros itens que fazem parte de uma governana SOA...................................16
Tabela 03 - Descrio de um arquivo WSDL na verso de WSDL 1.1...............................20
Tabela 04 - Descrio de um arquivo WSDL na verso 2.0 com SOAP 1.2...................... 22
Tabela 05 - Requisio SOAP usando protocolo http......................................................... 26
Tabela 06 - Resposta SOAP usando protocolo http.............................................................27

VII

LISTAS DE ACRNIMOS 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 Informao.

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 alcanar a eficincia em
uma corporao, oferecendo maior flexibilidade para adaptar s necessidades de negcios
que sempre esto em mudanas. Mas esta tarefa no simples e tem exigido grandes
esforos dos lideres e gestores de TI e mesmo assim, na maioria das vezes fica impossvel,
em tempo hbil acompanhar a regras impostas pelos analistas de negcios ou at mesmo
uma demanda de mercado.
Para aliar a TI a estratgia de negcio, permitir uma tomada de deciso precisa e
muito mais rpida, ser apresentado neste estudo uma nova metodologia, chamada de
SOA, onde a arquitetura dos sistemas de informao baseada em servio orientado, ou
seja, todo sistema ser divido em blocos de funcionalidades que podero ser ordenados ou
reordenados sem nenhuma restrio e com mnimo de esforo e custo.

Introduo
Em busca de maior flexibilidade, o mundo dos negcios em que vivemos cada

vez mais desafiador, e a busca constante por inovao, tornou uma estratgia no s para
empresa, mas para paises [TAURION, 2007].
Fundamentado nessa constante busca por inovao, ultimamente o departamento
de TI nas empresas esto convivendo com vrias geraes de tecnologia diferentes. E
pode-se afirmar que o resultado de uma grande parcela dos esforos, energia e
investimento gasto nas atividades de manuteno e integrao das aplicaes. Para criar
estas integraes, geralmente as ligaes entre as aplicaes so feitas ponto a ponto e a
frmula para integrao n(n-1) de conexes, onde n o nmero de aplicaes existentes,
demonstrado na figura 1.1. Sendo assim, uma empresa que tem dez aplicaes ativas, se
desejarem fazer uma integrao total sero necessrias 90 conexes e cada uma delas ter
que entender as caractersticas das outras aplicaes e conseqentemente quando esta
empresa precisar mudar seus processos ou as regras de negcios, a TI responder de forma
muito lenta, porque todas as conexes devem ser avaliadas ou modificadas [TAURION,
2007].

Figura 1.1 Conexes para integrao em um sistema no SOA. Fonte Caetano (2008).
Paralelamente a esse caminho complexo, sem flexibilidade e rduo, caminha e
ganha fora uma metodologia chamada SOA acrnimo de Service Oriented Architecture
(Arquitetura orientada a servio).
1

A metodologia SOA prope mudana no contexto de integrao, o princpio

dissolver as aplicaes em vrios servios, conhecido pelo termo em ingls Building
Blocks, o que possibilita o agrupamento e/ou reagrupamento, quantas vezes for necessrio
para construo de novas aplicaes ou readequaes aos novos processos e mudanas nas
regras de negcios. Seguindo este princpio pode-se comparar com um brinquedo lego
para exemplificar, onde com as mesmas peas podemos montar diversos objetos diferentes.
Na metodologia SOA as peas do brinquedo lego seriam os servios e os objetos seriam
as aplicaes. Seguindo este conceito, mudar as regras ou processos de negcios, seria
apenas uma nova remontagem de blocos de servios. No existindo custo e tempo para
desenvolvimento de novas aplicaes [CESAR, 2006].
Seguindo o caminho do SOA a TI daria uma grande salto na evoluo, passando a
ser uma BT (Business Techonology) assumindo a parte essencial e estratgia dos negcios
da empresa, segundo Taurion (2007).
Um dos principais benefcios 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 negcios da organizao [NEXTGENERATION,2007].

2 Viso Geral da SOA

Neste tpico ser abordado um parecer tcnico dos recursos envolvidos em uma
implementao SOA, tais como: Definio; Conceito de servios, interoperabilidade e
acoplamento fraco; Passos para adoo; SOA no Brasil e governana em SOA.
2.1 Definio
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 especfica de acordo com o negcio 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 servio, outra caracterstica muito interessante do
SOA a possibilidade do reuso de software, que reduz custo e esforo no desenvolvimento
e permite um atendimento aos novos requisitos com maior agilidade.
Em um ambiente SOA, os recursos de uma rede so disponibilizados como
servios independentes e podem ser alocados ou acessados sem conhecimento da
plataforma e linguagem que foram implementados.
SOA tambm pode ser conceituada como um estilo de arquitetura de sistemas
de informao que possibilita a criao de aplicaes que so construdas ao se
combinarem os servios fracamente acoplados e que funcionam em conjunto. Estes
servios operam entre si com base em uma definio formal (ou contrato, por exemplo,
WSDL) que independente da plataforma e da linguagem de programao. A definio da
interface esconde a implementao do servio especifico da linguagem. Os sistemas
compatveis com SOA podem, portanto ser independentes das tecnologias de
desenvolvimento e plataformas (como Java, .Net, etc)-(Josuttis, 2007)
SOA no uma arquitetura concreta, uma ferramenta ou framework com
possibilidade de compra e venda, mas sim, um paradigma, conceito, perspectiva, filosofia
ou representao e at mesmo uma estratgia metodolgica da TI que decide adot-la e
personaliz-la de acordo com cenrios da empresa. Como ponto positivo e para maior
estimulo, uma aplicao SOA, normalmente baseada em padres de web services, o que

permite maior interoperabilidade com independncia de padres, conhecidos como

especificao dos web services (SOAP ou REST), ambos com amplo apoio da indstria
nos dias atuais. Outro ponto positivo que SOA no necessariamente prende nenhuma
empresa de software proprietrio. No entanto ela pode ser implementada com uso de
qualquer tecnologia baseada em servio.
2.2 Conceito de SOA
Segundo Josuttis (2007) em seu livro SOA na prtica os principais conceitos
tcnicos que permitem lidar com as caractersticas de sistemas SOA so: Servios,
Interoperabilidade e acoplamento fraco.
2.2.1 Viso o que servio.
Servio so pores conhecidas como componentes de software, construdos 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 indstria especfica.

Figura 2.1 Processo de Faturamento usando vrios servios. Fonte [ERL, 2005]
4

A idia de servio definir partes dos cdigos de software em pores

significativas o suficiente para serem compartilhadas e utilizadas em diversas reas da
empresa. Vejamos o exemplo da figura 2.1 acima, onde o servio busca status produtivo do
pedido, que no determinado momento esteja sendo usado pelo servio de faturamento e ao
mesmo tempo ele poder ser alocado em outros departamentos para atender outros
requisitos como: controle de produo, estimativa de entrega pelo departamento de
logstica e at mesmo o sistema do portal disponvel na web.
2.2.2 Interoperabilidade.
Interoperabilidade a capacidade de resolver o problema de integrao
facilmente entre sistemas heterogneos. A idia de interoperabilidade surgiu com EAI, um
conceito de integrao de aplicao corporativa. Diferentemente de SOA em uma
aplicao baseada em EAI a interoperabilidade feita criando interfaces, ou seja, softwares
que tinham o propsito de traduzir e auxiliar na comunicao entre sistemas ou
plataformas diferentes, conforme figura 2.2.

Figura 2.2 Interoperabilidade usando interface em EAI. Fonte [PULIER e

TAYLOR,2007].
No entanto, para SOA o conceito de interoperabilidade o comeo para uma
implementao SOA, tambm a base a partir da qual comeamos a implementar as
funcionalidades de negcios(servios) e espalhada pelos diversos sistemas distribudos
existentes[JONES, 2006].
2.2.3 Acoplamento fraco.
Como o SOA aplicado em sistemas distribudos, a escalabilidade e a tolerncia
s falhas so as chaves para o sucesso e manutenibilidade dos sistemas envolvidos e
tambm possibilita minimizar os impactos das modificaes e das falhas dentro dos
sistemas.
O objetivo importante minimizar o impacto das modificaes e das falhas
dentro do cenrio do sistema como um todo. -(Josuttis, 2007).
Para resolver este problema imposto neste cenrio, existe dentro do SOA um
conceito chamado de acoplamento fraco, onde o objetivo minimizar as dependncias
6

tipicamente empregadas para lidar com os requisitos de escalabilidade, flexibilidade e

tolerncia s falhas.
Quando existem poucas dependncias, as modificaes ou as falhas em um
sistema tero menos conseqncia em outros sistemas. -(Josuttis, 2007).
O acoplamento fraco no uma ferramenta e nem uma lista de verificaes.
Portanto para projetar uma SOA necessrio definir quais tipos e qual quantidade de
acoplamento fraco sero introduzidos. No entanto, ser apresentado uma tabela a seguir
com alguns assuntos tpicos para considerar na implementao do acoplamento fraco no
sistema.
Tabela 01 Assuntos tpicos a ser considerado na implementao do acoplamento fraco
em um sistema.
Tipo

Acoplamento forte

Acoplamento

Conexes fsicas

Ponto a ponto

fraco
Atravs de mediador

Estilo de comunicao

Sncrona

Assncrona

Modelo de dados

Tipos comuns complexos

Apenas tipos comuns

Sistema de tipagem

Forte

simples
Fraco

Padro de integrao

Navegar atravs de rvores de

Mensagens

Controle de lgica de

objetos complexos
Controle central

independentes
Controle distribudo

processos
Ligao

Esttica

Dinmica

Plataforma

Dependncias de plataformas fortes

Independncia de

Transaes

2PC(Commit em duas fases)

plataforma.
Compensao

Deployment

Simultneo

Em tempos diferentes

Controle de verses

Atualizaes explcitas

Atualizaes implcitas

Consideraes proposta por Josuttis (2007).

2.3 XML
A inspirao para o projeto de XML veio de duas fontes distintas: SGML
(Standard Generalized Markup Language) e HTML(Hypertext Markup Language). A
verso 1.0 de XML foi disponibilizada pelo W3C(Word Wide Web Consotium) em 10 de
fevereiro de 1998, porm o projeto da linguagem foi iniciado em meados de 1996, com o
7

objetivo de produzir um mecanismo simples e extensvel para representao textual de

informao estruturada e semi-estruturada.
XML o padro que comeou a permitir o to desejado ideal de
interoperabilidade aberta. um dos marcos tecnolgico que muitas pessoas discutem e
poucas compreendem completamente [Pulier e Taylor,2007]. A XML leva a uma
interpretao pessoal de acordo com o local aplicado ou na explorao do tpico, sendo
neste contexto apresentado aqui, o mais apropriado afirmar que XML um conjunto de
padres que permitem os desenvolvedores alcanarem diversas tarefas [Pulier e Taylor,
2007].
Para ser mais claro, XML apenas um conjunto de padres 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 requisio, entre outros.
Em geral, o XML o novo formato de dados universal. Um formato de dados
uma conveno para se armazenar ou transmitir dados. (Pulier e Taylor, 2007).
A figura 2.3 um exemplo de uma transmisso ou armazenamento de um pedido
usando XML.

Figura 2.3 - Exemplo de um arquivo XML. Fonte [Caetano, 2008]

2.4 Web services

Inicialmente, a internet era constituda de pginas com dados ou informao de
forma esttica, e consultada somente por pessoas atravs de programas chamado de
navegador web, tambm conhecido como browser. Com a evoluo da internet e por
necessidade dos usurios as pginas comearam a ter contedo dinmico, proveniente de
banco de dados e outras fontes e tambm ficaram interativas, com possibilidade do usurio
inserir, alterar ou at excluir informaes contidas nas pginas [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 vrias solues, no lado servidor, para
a construo de aplicaes que sejam capazes de extrair dados de diversas fontes e
disponibilizar para os usurios atravs do navegador web. Mas s as construes dessas
aplicaes no 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 padres abertos para
interoperabilidade, esses padres permitem a interoperao global de computadores,
independente de plataforma de hardware, sistema operacional, infra-estrutura de rede ou
linguagem de programao.
Baseados em XML e em tecnologia abertas como WSDL, UDDI e SOAP, web
services apresentam-se como uma das possibilidades para a implementao do
compartilhamento de recursos e a integrao entre sistemas corporativos empregando a
internet como meio de comunicao. Suas trs principais vantagens esto embasadas no
fato de funcionarem sobre padres estabelecidos na internet (XML, HTTP, TCP/IP).
( Abinader e Lins, 2006).
Comparando web service com a computao distribuda tradicional de troca de
mensagem atravs de interfaces proprietria, 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 requisio 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 Comunicao web service entre um consumidor e fornecedor usando o

protocolo SOAP. Fonte [PULIER e TAYLOR,2007].
2.5 Os passos para adoo da SOA.
Ser apresentado a seguir uma breve viso de dois especialistas em SOA. Como
adotar esta nova metodologia com sucesso e no cometer erros na implementao.
O especialista em SOA Lheureux1 (2007), apresentou na 5 conferencia anual de
integrao empresarial, os passos essenciais para uma implementao bem sucedida de
SOA. Segundo ele so quatros passos importantes: introduo, disseminao, explorao
de resultados e plat [NEXTGENERATION, 2007].
Introduo - preciso definir um projeto-piloto. A implementao segmentada
reduz os investimentos, permite mostrar as melhorias para alta direo sem ter que
enfrentar o risco de colocar SOA na empresa inteira.
Disseminao - Concluda a primeira fase com sucesso, o desafio espalhar esse
conceito para as outras reas, aumentando o escopo de atuao e as pessoas envolvidas.

Benoit Lheureux, vice-presidente e analista do Gartner.

10

Explorao de resultado - Qualquer projeto precisa de bons resultados num

prazo razovel. Documentando os benefcios resultantes da implementao, a adoo
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 organizao.
Segundo Lheureux (2007) o gestor que pular uma das etapas ter o fracasso
garantido.
Atualmente a maioria das empresas est entre a introduo e disseminao do
conceito. Assim, independente do pas em que empresa se encontra ningum est muito
distante em SOA.
Em pesquisa realizada pela IDC2, em Londres, durante a conferncia sobre SOA,
60% de um grupo de 140 executivos de TI responderam que ainda esto investigando essa
arquitetura. A pesquisa tambm mostrou que SOA ainda no foi completamente assimilado
[NEXTGENERATION, 2007].
Segundo Josuttis (2007), em seu livro SOA na prtica, ele apresenta um exemplo
tambm baseado em passos, como: entender, definir um projeto piloto em segundo e o
terceiro e por fim crescer e tornar-se uma estratgia geral.
Entender SOA - O principal objetivo entender, uma empresa no pode
comear mudar toda sua arquitetura para SOA porque est moda ou porque seu analista de
negcio recomenda ou at mesmo enxergar um beneficio. Segundo ele o benefcio nem
sempre fcil de enxergar, aprender sobre as diferenas entre os sistemas grandes e
pequenos e entre o controle central e distribudo, isto fundamental.
Alm disso, antes de seguir este caminho, totalmente necessrio que o seu
gerenciamento aceite que SOA uma estratgia, e no uma soluo pronta, e tambm
entender as possveis conseqncias de implementar esta estratgia, e em especial o que
significa ter processamento distribudos. No nvel gerencial necessrio ter domnio nos
detalhes, controle de verses, e total compreendimento sobre o conceito de acoplamento
fraco [JOSUTTIS, 2007].
Um outro ponto importante segundo Josuttis (2007). SOA no a soluo para
qualquer tipo de integrao de sistemas, ao contrrio, ela um conceito para lidar com
2

IDC, empresa de consultoria e conferncias nos segmentos de Tecnologia da Informao e

Telecomunicaes.

11

processos de negcios distribudos. A replicao de banco de dados e desacoplamento de

front-ends3 e back-ends4 so totalmente diferentes, embora elas possam usar os mesmos
padres 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 produo alguma
funcionalidade que inclui alguns processamentos de negcios atravs de dois ou trs
sistemas diferentes. Neste projeto inicial, a empresa concentrar principalmente nas
decises tcnicas e arquiteturais. No entanto, isso deve ser guiado pelas necessidades de
negcio. Isto significa que a equipe que realiza esse piloto deve ser uma mistura de pessoas
de negcio e pessoas de TI [JOSUTTIS, 2007].
No estagio inicial necessrio ter muito cuidado, continua Josuttis (2007), dando
algumas orientaes: Use apenas servios bsicos, o que significa iniciar com SOA
fundamental; use apenas um ou dois padres MEPs5, recomendado comear com padro
requisio/resposta sncrono ou assncrono; defina um conjunto mnimo 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 princpio, isto no ser necessrio; pense sobre
a quantidade de segurana e manutenibilidade que quer prover no momento atual e
momento futuro e por fim sempre pense grande e comece pequeno.
O foco mais importante, alm de executar software, deve estar em prover
interfaces excelentes entre o ESB e o negcio. A empresa no tem que decidir aqui sobre
os processos. Primeiro necessrio de software funcionando, depois criar, gerar ou
implementar, isso em um processo de desenvolvimento de software distribudo. Do ponto
de vista de negocio, no se pode comear com um servio composto ou de processos muito
complexo. O objetivo desta abordagem fornecer alguma funcionalidade tpica de backend com a nova infra-estrutura de SOA, talvez v substituir algum acesso remoto a banco
de dados por um servio. A funcionalidade implementada deve ter algumas relevncias
para o negcio. Embora seja provavelmente muito arriscado para ser de misso crtica para

3
4
5
6

Front-ends, a parte do sistema de software que interage diretamente com o usurio [Wikipedia, 2008].
Back-ends, a base de dados e fica por trz de um front-end [Nogueira, 2008].
MEPs Padro de mensagens requerido em um padro de protocolos de comunicao[Wikipedia, 2008].
Middleware Programa que faz mediao entre outros softwares[Wikipedia, 2008]

12

a empresa, implementar alguma funcionalidade til necessria 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 so fases
muito importantes na introduo de SOA, nesta fase comea-se pensar sobre todas as
coisas importantes que levam aos efeitos sinrgicos e considerar a reusabilidade dos
servios. Definir processos para equipes diferentes, encontrar o equilbrio certo entre
centralizao e descentralizao e encontrar o ponto certo entre a teoria ou conceitos e a
prtica se torna importante.
Segundo Josuttis (2007) medida que aumenta os nmeros de projetos, o
gerenciamento de multiprojetos deve ser pensado, A Figura 2.5 abaixo demonstra isso em
relao infra-estrutura comum dos trs pilotos. Primeiro projeto piloto cresce com a
infra-estrutura. O segundo e o terceiro projeto pilotos so baseados nas experincias,
decises e implementaes anteriores, mas precisam e adicionar novos recursos que tem
impactos na infra-estrutura geral, causando uma alterao na infra-estrutura inicial. Estas
mudanas no sero apenas adies de novos recursos. A maioria sero atualizaes
baseadas em consolidao e generalizaes. Interfaces, processos e polticas teis evoluem
medida que voc as usa e convive com elas. Sempre que um mesmo esforo for repetido
pela terceira vez, ser necessrio fazer algo para automatizar estes processos conhecido
pela comunidade XP como, Trs Strikes, esta automao leva o desenvolvimento orientado
a modelos.

Figura 2.5 Dependncias entre a infra-estrutura e mltiplos projetos. Fonte [JOSUTTIS,

2007].
Otimizar para no fazer as funes repetidamente uma boa abordagem para
alcanar a excelncia. No entanto, observe que o modelo de programao comum em
13

grandes projetos na abordagem copiar e colar. Na SOA o contrrio, para se beneficiar

das melhorias, ter que refatorar os projetos pilotos que j esto em fase terminados, caso
contrrio os desenvolvedores iro copiar os cdigos e APIs antigas e depreciadas
[JOSUTTIS, 2007].
O padro trs Strikes no se aplica apenas aos aspectos de infra-estrutura.
Baseado na figura 2.5 anterior, a palavra infra-estrutura pode ser substituda por processo,
ciclo de vida, polticas, arquitetura entre outras. O importante entender que o aspecto
SOA sempre est em evoluo, o que significa ter os recursos sempre flexveis para que
sempre que seja necessrio modificar as prticas, os cdigos existentes e manutenibilidade
para alcanar consistncia melhor.
Crescer e tornar-se uma estratgia geral Para que a empresa tenha a
possibilidade de detectar mais rpido as oportunidades e desafios de negcios, ser
necessrio gerenciar SOA, gerenciar servios, contratos de servios e o monitoramento de
atividades de negcios [JOSUTTIS, 2007].
Para que isso ocorra crucial neste estgio que a maneira usual de estabelecer
novas funcionalidades de negcios seja completamente descentralizada e automatizada ao
mximo, e para alcanar isso s equipes de servios centrais ter que ter domnio em suas
funes, isto normalmente requer muitos recursos, mas o importante no parar o suporte
estratgico de SOA neste ponto.
Embora com o tamanho aumentado os aspectos de sua estratgia SOA se
tornem mais e mais estveis, sempre h novos requisitos com que lidar. Eles podem ser
tcnicos (Devemos mudar para o novo padro do protocolo?) ou de negcio (Como
estabelecemos uma conexo B2B que usa um protocolo ligeiramente diferente?). crucial
aqui que as modificaes da plataforma SOA e os processos sejam orientados a negcio.
As infra-estruturas de servios devem servir s equipes de negcios. Josuttis (2007).
2.6 SOA no Brasil, como e quando implantar.
A SOA no Brasil ainda est em fase embrionria, sua adoo muito discutida
por executivos de TI, que precisam entender que possvel comear um projeto dessa
dimenso sem antes instaurar uma poltica de governana [NEXTGENERATION, 2007].
Alguns especialistas aconselham a comear a implantao pelos processos mais
crticos do negcio e tambm sugerem que as organizaes comecem a implantar SOA aos
14

poucos, orientam que a adoo de novas arquiteturas pode ser feita em etapas, conforme
demandas forem surgindo. Segundo eles o ideal que as empresas apliquem SOA
inicialmente em processo crticos que exijam mais agilidade, como os sistemas onde a
lgica de negcios possa ser facilmente desagregada da parte de apresentao.
Uma vez que as organizaes decidam aderir SOA, elas precisam se certificar de
que os projetos nascero baseados na arquitetura e quando forem desenhar a arquitetura do
sistema, o responsvel pelo projeto deve ter SOA em mente [NEXTGENERATION,2007].
Desde a concepo do sistema, nova arquitetura deve ser levada em considerao.
Alguns dos pesquisadores do SOA no Brasil, segundo a Nextgeneration (2007),
afirmam que durante a implementao do projeto SOA, as equipes identificaro servios
no muitos utilizados, mas dos quais as empresas tambm no devem descartar. Com SOA,
algumas funcionalidades sero abstradas e outras integradas. A arquitetura elimina
retrabalho. As empresas devem construir um catalogo de servios e utiliz-los para outras
aplicaes. J outros especialistas acreditam que o desafio para a adoo de SOA esto
muito mais do lado organizacional e cultural da empresa, do que em seu aspecto tcnico
[NEXTGENERATION,2007].
2.7 Governana em SOA.
Esse tipo governana focado no ciclo de vida dos processos, servios,
metadados e na composio das aplicaes de uma empresa que utiliza SOA. Governana
SOA define as mudanas da governana de TI para assegurar os conceitos e princpios de
SOA, ou seja, uma especializao de governana de TI. Pela sua funcionalidade,
governana SOA tambm prov um framework para examinar diversos itens necessrios
para o gerenciamento dos servios em uma TI, segundo Erl (2005) os principais itens so:
Maturidade dos servios;
Infra-estrutura para a gerencia dos servios (segurana, monitoramento,
performance, versionamento e compartilhamento);
Granularidade e reuso dos servios;
Educao e treinamento;
Regras e responsabilidades;
Mudanas organizacionais.
As atribuies da governana SOA so:
15

Tabela 02 Outros itens que fazem parte de uma governana SOA, segundo Jones (2006).
Registro
Desenvolvimento
Versionamento
Modelagem
Proprietrio
Publicao
Juno
Discovery
Monitoramento
Reutilizao
Auditoria
Acesso
Diagnstico
Implementao
Identificao
Segurana
Consumo
Tabela traduzida do livro Enterprise SOA Adoption Strategies [JONES, 2006].
Um dos principais pesquisadores sobre SOA Josuttis (2007), afirma que
governana em SOA um obrigao e o nvel de detalhes e riqueza est totalmente
relacionado ao tamanho do projeto em questo.
Governana da arquitetura orientada a servio no uma opo, ela uma
obrigao. Quanto maior SOA, mais governana ela precisa e mais complexos papis e
mecanismos da governana devem ser. Os arranjos da governana 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 no uma tecnologia especfica a sua implementao, na maioria das
vezes baseada em padres existente, ser apresentado neste tpico as mais comuns e mais
utilizadas nas empresas atualmente.
3.1 Padres
Os principais benefcios de SOA so claros, como a reutilizao dos ativos
existentes, mas o panorama dos padres ainda no so totalmentes claro. Em um estudo
recente sobre o assunto, segundo Violino (2008), a Forrester Research contabilizou cerca
de 120 padres flutuando ao redor de SOA e Web services. Descobriu tambm que quase
impossvel confirmar quais fornecedores suportam quais padres. Mesmo assim, os CIOs
tm que seguir em frente com projetos SOA para satisfazer as necessidades do negcio
[VIOLINO, 2008]. E tambm afirma que vrios CIOs como, Hong Zhang, diretor e
arquiteto chefe de arquiteturas e padres de TI da General Motors, tem obtido um
equilbrio entre o dilema dos padres e a utilizao contnua de SOA, conforme citao
abaixo.
bom que existam vrios padres relacionado a SOA, isso indica que a
indstria de software ruma para ampla adoo de SOA, o desafio no haver uma
framework arquitetural comum, consistente, para orientar a evoluo, a integridade e a
intregrao destes padres. Muitos deles ainda no atingiram a maturidade. Citado por
Violino (2008).
Conforme vrias abordagens trivial afirmar que a maioria das implementaes
de SOA nas empresas utilizando web services [WIKIPEDIA, 2008]. Baseando nisto ser
apresentado o padro de web services mais comum e adotado pelas empresas, conhecido
por pilha de padres WS-*.
3.1.1 WS-*.
Os web services WS-* surgiram no final da dcada de 90, quando fabricantes de
midleware perceberam a necessidade de padronizar as implementaes de SOA que
estavam surgindo [PEREIRA7,2007]. Isto era o ponto chave para garantir a

Bruno Pereira, desenvolvedor Java snior e lder de equipe da Concrete Solutions.

17

interoperabilidade de aplicaes. Sem a viso de interoperabilidade a metodologia SOA

no faria nenhum sentido afirma Pereira (2007).
O rpido crescimento dos servios WS-* se distinguiram pela velocidade das
especificaes muito superior velocidade das aplicaes prticas destes padres. Tais
procedimentos cresceram rapidamente e chegou a um ponto no qual ficou praticamente
impossvel acompanhar o ritmo da documentao gerada pelo consrcio de empresa
envolvidas,

isto

certamente

elevou

complexidade

das

implementaes

[PEREIRA,2007].
O grupo responsvel a garantir a interoperabilidade de web services desenvolvida
em diferentes plataformas o WS-I, este grupo adotou como referncia para todas as
implementaes da pilha de padres WS-* da plataforma Java, um conjunto de definies
chamado Basic Profile 1.0. Outra parte importante a respeito adoo do Basic Profile
que a Microsoft tambm adotou estas definies para pilha de SOA .NET 8. Partindo deste
princpio o uso deste padro garanti uma integrao bem sucedida entre as duas
plataformas segundo Pereira (2007).
Os web services WS-* tem em sua pilha trs padres importantes que
necessariamente devem ser considerados so eles: WSDL , SOAP e UDDI [ABINADER e
LINS, 2006].
3.1.1.1 WSDL
O WSDL tem a funo de descrever de modo a preencher lacunas principais
como: informar o consumidor o que o servio executa como o consumidor pode invocar o
servio e como o consumidor pode diferenciar servios similares, oferecidos por diferentes
fornecedores. Com esta descrio, o cliente consumidor interessado em utilizar o web
service, pode fazer de forma automtica, sem que seja necessria a interveno ou contato
como o autor fornecedor do mesmo [PULIER e TAYLOR, 2008].
Partindo para uma viso mais tcnica o WSDL usado para definir as interfaces
dos servios. Ele pode descrever dois aspectos diferentes de um servio: Sua assinatura
(nome e parmetros) e seus detalhes de ligao e deploy (protocolo e localizao)
[JOSUTTIS, 2007].

.NET, Linguagem de programao da Microsoft.

18

Para um melhor entendimento do WSDL ser apresentado na figura 3.1 a

estrutura geral dos arquivos na verso 1.1 e a recm lanada 2.0.

Figura 3.1 Estrutura geral de arquivo WSDL 1.1 e 2.0. Fonte Josuttis (2007).
Os arquivos WSDL descrevem os servios de baixo para cima, ou seja, eles
comeam com os tipos de dados usados e terminam com o endereo do servio e contm
trs camadas de descrio [JOSUTTIS,2007].
A primeira camada chamada na verso 1.1 de tipo de porta descreve a interface
de um servio e pode consistir uma ou mais operaes com parmetros de entrada e sada
que usam os tipos especificados na primeira seo do arquivo. Na verso 1.1 os
parmentros de servios so definidos nas sees <message>, enquanto na verso 2.0 eles
so definidos como qualquer outro tipo na seo <types>.

19

A segunda camada define a ligao de um web service, ou seja, o protocolo e o

formato para quais operaes de web service so oferecidas.
J a terceira e ultima camada define a localizao fsica (endereo, URL) onde
web service est disponvel.
Para um melhor entendimento sero apresentados na tabela 03 a descrio WSDL
nas duas verses. O WSDL proposto define um servio de informao de um pedido, onde
o consumidor do servio informa a um atributo numero do tipo inteiro e tem uma sada de
atributos em formato string: cliente, endereco e float: valorTotalPedido.
Tabela 03 - Descrio de um arquivo WSDL na verso 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 prtica [JOSUTTIS, 2007].

Para uma anlise detalhada no arquivo ser apresentado por funcionalidade das
sees, percebe-se que os arquivos WSDL descrevem os servios de baixo para cima e
assim ser analisado.
A seo <service> define um servio chamado de PedidoService na URL
http://www.cristaltemper.com.br/pedido11, a qual fornecida com uma ligao 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 seo <binding> define o protocolo e o formato que so utilizados para fornecer os
servios. Neste local temos a definio de PedidoSOAPBinding. No seu inicio j especifica para
qual tipo de interface a ligao PedidoInterface, sem se preocupar com detalhes, a ligao
SOAP utilizando o protocolo http.
A seo <portType> define a interface PedidoInterface. Ela versa de uma operao
chamada getDadosPedido e especifica as mensagens que sero enviadas atravs ESB quando
essa operao chamada. Este servio e baseado em mensagem de requisio e resposta, com
requisio em getDadoPedidoInput e resposta em getDadoPedidoOutput.
A seo <message> define mensagens individuais, fazendo uso dos identificadores
referenciados da seo <portType> Tanto o mtodo de requisio e resposta usam um tipo de dados
definido na seo <types>.
A seo <types> define os tipos de dados de entrada e sada.

Tabela 04 - Descrio de um arquivo WSDL na verso 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 prtica [JOSUTTIS, 2007].

Como demonstrado no arquivo anterior existe algumas diferenas entre elas,
como:
A tag raiz chamada de <description> diferentemente da verso 1.1 a qual
chamava de <definitions>;
A seo <service> usa endpoint e no <port>;
Dentro da seo <binding> definem o protocolo especifico;
A seo <portType> substituda por <interface>. Ela usa padres de troca de
mensagens mais especficos, que definem a ordem de baixo para cima;
Usa namespaces diferentes para identificar WSDL 2.0 e SOAP 1.2;
Elimina a seo <message> e as operaes passam a referenciar diretamente aos
<types> (tipos de dados).
3.1.1.2 SOAP
SOAP um protocolo para troca de informaes estruturadas em uma plataforma
descentralizada e distribuda, este protocolo e baseado em XML e possibilita a
comunicao efetiva entre sistemas distribudos estabelecidos sobre conjuntos de software
e hardware heterogneos.
24

SOAP um protocolo projetado para invocar aplicaes remotas atravs de

RPC ou trocas de mensagens, em um ambiente independente de plataforma e linguagem
de programao. SOAP , portanto um padro normalmente aceito, para utilizar-se com
Web Services. Desta forma, pretende-se garantir a interoperabilidade e intercomunicao
entre diferentes sistemas, atravs da utilizao de uma linguagem (XML) e mecanismo de
transporte (HTTP) padres Cunha (2002).
Como a tecnologia deste protocolo XML, ento sua especificao 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 programao ou outra implementao [WIKIPEDIA, 2008].
Uma das caractersticas mais importantes do SOAP a separao do formato de
dado a ser transmitido, do protocolo de nvel inferior que ir transportar o dado,
produzindo independncia 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 trs elementos, envelope, header
(cabealho) e body (corpo), conforme figura 2.7,
Envelope: Deve existir em todas as mensagens. o elemento raiz do documento
XML. O Envelope pode conter declaraes de namespaces e tambm atributos adicionais
como o que define o estilo de codificao.
Header: Este elemento opcional. Ele leva informaes adicionais, para ajudar a
infra-estrutura a lidar com as mensagens como dica de roteamento, segurana e outros. Se
o cabealho header for definido ele deve ser o primeiro elemento do Envelope.
Body: Este elemento obrigatrio e contm o payload, ou a informao 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 ns 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 so encapsuladas ou serializadas segundo o padro SOAP. O destinatrio
servidor, ao receber a mensagem faz o processo contrrio, desencapsulando-a e extraindo
as chamadas de mtodo. 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 - requisio 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 padro SOAP
responsvel pelo transporte das mensagens e o padro WSDL responsvel pela descrio
dos servios, ambos so mantidos pela W3C e o padro UDDI uma especificao tcnica
que tem como objetivo descrever, descobrir e integrar web services e mantido por um
grupo de empresas do mundo dos negcios. Segundo a OASIS o UDDI um elemento
central do grupo de padres que compe a pilha de componentes dos servios web
[RECKZIEGEL,2006].
27

Foi inicialmente parte de um termo ainda mais amplo UBR [JOSUTTIS, 2007]. A
idia original era introduzir todos os trs papis de um mercado em funcionamento:
Fornecedores que oferecem servio a um consumidor que precisa de um servio e brokers
que juntam os dois divulgando e localizando os servios, como na figura 2.8.

Figura 3.3 - Modelo UBR. Broker, fornecedor e consumidor. Fonte Josuttis (2007).
A inteno por trs de UBR era que isso seria o broker central para um mercado
mundial de web services, como se fosse um catlogo telefnico que tem pginas brancas,
amarelas e verdes para que os fornecedores pudessem divulgar seus servios e os
consumidores localizarem quaisquer servios desejados, onde:
As pginas brancas: contm informaes sobre nomes, endereos, nmeros de
telefone, alm de outras informaes sobre os fornecedores do servio.
As pginas amarelas: contm listagens comerciais baseadas nos tipos desses
negcios, de maneira organizada por categoria especfica ou regies demogrficas.
As pginas verdes: so usadas para indicar os servios oferecidos por cada
negcio, incluindo todas as informaes tcnicas envolvidas na interao com o servio.
Resumindo, explica como fazer a comunicao com eles.
Porm essa idia inicial no 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 alcanados e seriam descontinuados na data acima.
28

A falha de UBR no significa necessariamente que UDDI tambm falhou, mas

h duvida sobre quo importante UDDI na prtica. Parte da razo que o
gerenciamento de servios requer um portiflio de servios significante para ser til. Mas
outra parte apenas dever de casa insuficiente. Josuttis (2007).

29

4 Responsabilidade de um ESB (Barramento de servio corporativo) em SOA.

Uma das idias da SOA disponibilizar servios que podero ser utilizados por
outros servios existentes na empresa. E o service requester (aplicao cliente) no tm a
necessidade de ter nenhum conhecimento da linguagem de programao ou tecnologia
utilizada para implementar o servio solicitado[MUNDO JAVA, 2007].
Na figura 4.1 mostra uma aplicao, cliente chamando diretamente servios
disponibilizados em uma aplicao Java com uma stored procedure. Se forem necessrios a
criao de um novo servio em outra linguagem e precisar ser integrado aplicao, ser
necessrio escrever mais cdigo para esta integrao.

Figura 4.1 Aplicao chamando servios sem o uso do ESB. Fonte Mundo Java (2007).
Se o service requester no sabe ou no quer se preocupar sobre as variaes como
os servios do service provider foi implementado e como deve requisit-lo ou em um
determinado momento queremos abstrair cada um dos servios existente no service
provider como web service, esta seria a soluo. Mas se fossem necessrio criar web
services para cada servio, no seria possvel disponibilizar como servios para que
pudessem ser acessado de qualquer outro lugar.
Neste cenrio o ESB resolveria com pouco esforo, conforme a figura 4.2. Um
service requester (aplicao cliente) pode solicitar servio, implementados de forma
diferente, atravs de um intermedirio que consegue se comunicar com cada uma das
implementaes dos servios necessrios.

30

Figura 4.2 Aplicao cliente chamando servios pelo ESB. Fonte Mundo Java (2007).
Existem diversas funcionalidades, como: roteamento, segurana, gerenciamento
de transaes, orquestrao de servios, coreografia de processos, processamento de
mensagem, mapeamento de servios, transformaes de protocolos, enriquecimento e
transformao

de mensagens.

Podem ser encontradas

em um ESB segundo

Galdino9(2007). Mas nem todos ESBs disponveis no mercado implementam todas essas
funcionalidades. Dentre elas o mnimo necessrio o roteamento, mapeamento de servios
e processamento de mensagens [GALDINO,2007], e segundo Silva10 (2008) um ESB deve
prover os recursos como:
Invocao: Para executar funes em servios assncronos e sncronos;
Roteamento automtico: Para independncia de localizao dos servios;
Mediao: Para converter e transformar arquivos (XML, CSV, etc) em dados;
Coreografia de processos: Para executar processos complexos e manter a
integridade das informaes;

Fernado Galdino desenvolvedor de projetos J2EE e SOA no Banco JPMorgan

Edgar A. Silva Arquiteto da JBoss e desenvolvedor de middleware de misso crtica em SOA.

10

31

Orquestrao de servios: O que capacidade de organizar ordens ou

colaboraes entre os servios em busca de um processamento descentralizado, porm
colaborativo para um resultado consolidado e confivel;
Suporte a mensageria: O que capacidade de processar mensagens e
proporcionar um ambiente reativo a eventos dentro do barramento nico;
Servios adicionais e gerenciamento: Transaes, segurana, logging e
auditoria.
Suporte a eventos das aplicaes: Como uma transao ou um simples envio de
byte de um protocolo, podem significar um evento que dispara vrios servios numa
corporao.
Um ESB formado pelos seguintes componentes, conforme figura 4.3.

Figura 4.3 Componentes de um ESB. Fonte Richard (2008).

O mediator responsvel por funes como roteamento, comunicao,
transformao e enriquecimento de mensagens, e manipulao de erros.
O service registry responsvel por mapear todos os servios que sero
disponibilizados.
O choreographer responsvel pelo processo de coreografia dos servios,
gerenciamento das transaes e segurana.

32

E rules engine: Pode ser usada em alguns outros componentes para auxiliar no
roteamento, transformaes e enriquecimento das mensagens.
4.1 Principais diferenas entre ESBs.
As diferenas entre os ESBs podem ser tecnicamente e conceitualmente. Uma
soluo pode no 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 so utilizadas pelos projetistas, desenvolvedores e operadores dos
servios.
Para um melhor entendimento sero apresentados diversos tipos de ESB, que
podem ser implementados sistemas especficos.
4.1.1 ESB com conexes ponto-a-ponto e mediao.
Nos ESBs de conexes ponto-a-ponto conforme figura 4.4, os consumidores
devem conhecer previamente o endereo final do fornecedor de servios. Conhecendo os
endereos do fornecedor, o consumidor envia requisio diretamente para ele. Principal
problema encontrado neste caso quando o fornecedor estiver inoperante ou inacessvel
chamada simplesmente falha.

33

Figura 4.4 Exemplo ESB fornecendo conexes ponto-a-ponto. Fonte Josuttis (2008).
J nos ESB com conexo mediadas, o consumidor no precisa conhecer o
endereo final do fornecedor, ele apenas identifica o servio por uma tag (etiqueta) ou um
nome simblico e os ESBs so responsveis pela localizao do fornecedor do servio,
conforme mostrado na figura 4.5. Como em alguns casos a prioridade e poltica dos
consumidores no so iguais, estes ESBs podem exercer o papel de um mediador ou broker
deixando esta infra-estrutura fracamente acoplada.

34

Figura 4.5 Exemplo de conexes mediadas por ESB. Fonte Josuttis (2008).
Um ponto importante desta conexo indireta que ela pode ter vrios
fornecedores de um mesmo tipo de servio, caso haja necessidade de balancear carga e
tolerncia s falhas.
4.1.2 ESB com interceptores.
Uma abordagem deste ESB substituir o ponto fsico final que fornece o servio
por um hardware ou software para fazer o balanceamento de cargas. Ele tambm baseado
no protocolo ponto-a-ponto, porm suporta chamada de servios indireta, oferecendo os
chamados atravs de proxies ou interceptores. Os consumidores que desejarem utilizar
estes servios 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 servios, de acordo com critrios pr-estabelecidos.

35

Figura 4.6 ESB utilizando um nico interceptador para vrios 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 vrios fornecedores, este utiliza um interceptador
para cada fornecedor, o que o torna bem mais complicado e obriga o consumidor a fazer
conexes ponto-a-ponto apenas com o seu inteceptor especfico, conforme figura 4.7. O
inteceptor ir rotear cada chamada para o fornecedor apropriado. Um ponto positivo desta
tcnica que os servios neste ESB podem ser encapsulados do mundo exterior atravs 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 comea do ponto vista dos consumidores e fornecedores, segundo Josuttis (2008) as
diferenas entre essas abordagens tm 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 comunicaes, conforme figura 4.8. Este tipo
de ESB utilizado em web services que requerem o uso do protocolo SOAP.

Figura 4.8 - ESB com conexes 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 implementaes e chamada de servios, conforme figura 4.9.

Figura 4.9 - ESB com conexes orientadas a APIs. Fonte Josuttis(2008).

37

Segundo Josuttis (2008), normalmente a abordagem orientada a protocolo leva a

uma terceira camada do modelo das comunicaes distribudas, demonstrada na figura
4.10. Na parte inferior do modelo existe um protocolo bastante estvel, j na parte superior
existe um API para chamar e implementar os servios. E entre a parte inferior e superior
existe uma camada responsvel por fazer a integrao.

Figura 4.10 Camadas do cdigo de negcio at o cdigo de protocolo. Fonte

Josuttis(2008).
percebido que os protocolos iro mudar ao longo do tempo. Por esta razo, em
algum momento todas as empresas que usam web services, adotam uma camada de
mapeamento, a qual parte do ESB [JOSUTTIS, 2008].

38

5 Segurana 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 avanada, o problema de segurana tem
contribudo para um avano mais lento ou at mesmo nenhum avano em algumas
empresas.
Segundo Pulier e Taylor (2008), segurana sempre foi uma preocupao para os
gestores de TI em grandes companhias. Atualmente grandes e robustos sistemas so
projetados para proteger os dados e informao contra uso no autorizado, intruso e vrus.
Os web services que praticamente base de SOA foram desenvolvidos por
consenso da indstria, com o foco em cdigo reutilizvel, simplificar o desenvolvimento e
integrao entre sistemas. Embora estes objetivos tenham sido alcanados, os padres
abertos que surgiram no tratam completamente a segurana. Especificamente o XML,
SOAP, WSDL e UDDI so padres abertos que permitem a transmisso e descrio de
dados, chamadas de procedimento entre sistemas e nenhum deles contem qualquer aspecto
de segurana implementado, sozinhos so totalmente inseguros [PULIER e TAYLOR,
2008].
Partindo de um princpio que os padres sozinhos so totalmente inseguros, como
percebida uma tendncia natural para adoo da SOA nas empresas, se torna necessrio
uma medida de segurana. E quando se fala sobre segurana em sistemas distribudos,
muitos aspectos devem ser considerados. E as principais categorias como autenticao,
autorizao, privacidade, integridade, disponibilidade, contabilizao e auditoria devem ser
definidas como os primeiros itens do requisito de segurana.
5.1 Autenticao e autorizao.
No modelo de segurana tradicional, a utilizao de um firewall ou uma VPN,
evita o acesso de usurios ou sistema no autorizado. Porm, uma SOA demanda que a
arquitetura seja mais flexvel e aberta para ser acessada por diversos sistemas para facilitar
a reutilizao e o desenvolvimento de novas aplicaes, e se o sistema for exposto em web
services mais um ponto inseguro aberto, pois um harcker pode configurar uma mquina
com servio semelhante para passar como um fornecedor e realizar chamadas de servios
errnea e fraudulenta [PULIER e TAYLOR, 2008], conforme exemplificado na figura 5.1.

39

Figura 5.1 Modelo de segurana em uma aplicao tradicional com firewall e web
service sem segurana. Fonte Pulier e Taylor(2008).
Para resolver este problema imposto necessrio criar uma autenticao para
verificar a identidade de quem est chamando o servio, se a identidade for vlida cabe ao
mtodo de autorizao verificar quais tipos de servios e resposta o consumidor tem
acesso.
5.2 Privacidade e integridade.
A privacidade de dados manter os mesmos confidenciais enquanto estiver em
trnsito ou em armazenamento. Na tica de servio isso significa garantir que ningum que
no seja o consumidor tenha acesso de visualizao aos dados enquanto estiver trafegando
entre o fornecedor e o consumidor. J a integridade a garantia de que os dados no sejam
manipulados ou falsificados; um dos fatores mais importante em um TI. Uma infraestrutura que no pode garantir um alto nvel de privacidade e integridade no
considerada segura.
Em uma SOA com um nvel inadequado de privacidade e integridade, um hacker
atravs de uma mquina no autorizada poder interceptar mensagem SOAP em trfego e

40

espionar ou alterar com propsito de fraude ou maliciosamente [PULIER e TAYLOR,

2008], como mostrada na figura 5.2.

Figura 5.2 Interceptao, roteamento e modificao das mensagens SOAP por um

Hacker ou pessoa no autorizada. Fonte Pulier e Taylor(2008).
Este cenrio mostra claramente a necessidade de criptografar s mensagens
SOAP entre os sistemas.
5.3 Inundao.
Uma SOA no-segura e aberta para todos, usurios mal intencionados ou
maliciosos, mesmo sem autorizao para usar o servio, pode usar alguma tcnica para
gerar inmeras requisies forando o servio a ficar inoperante. Este ataque conhecido
como DoS(negao de servio) o seu principal objetivo de impedir que usurio legtimo
utilize um determinado tipo servio, devido a sobrecarga no sistema em atender as
requisies falsas, demonstrada na figura 5.3.

41

Figura 5.3 Inundao com requisio ao servio em uma SOA no segura. Fonte. Pulier
e Taylor (2008).
Um fator que torna o DoS um risco muito srio a falta de capacidade da SOA
no-segura de monitorar ou garantir os nveis e desempenhos dos servios de seus web
services pois se um hacker atacar, ela no possui nenhuma maneira inerente de dizer que
est sobrecarregada e nem permite aos administradores do sistema identificar e responder a
problemas de segurana rapidamente [PULIER e TAYLOR, 2008].
5.4 Auditoria
O objetivo avaliar um conceito de segurana de uma aplicao e melhorar a sua
confiabilidade. Auditoria pode ser definida em gravar todas as informaes relevantes
segurana para que em uma anlise futura possa detectar falhas e possveis ataques, como
parte de uma auditoria em sistemas inclui monitorar e guardas logs e rastrear fluxo de
dados que so relevantes. Auditoria em algum momento pode ser um componente
funcional, quando um permite manipulao e alterao de dados [PULIER e TAYLOR,
2008].
Um log de auditoria uma ferramenta fundamental de segurana de TI. Para
examinar o desempenho de segurana de diagnosticar problemas de segurana, 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 incio da SOA a meta de muitas empresas era simplesmente
disponibilizar funcionalidade de aplicaes com servios compartilhados. Mas nos ltimos
dois anos o lado do negcio adquiriu melhor percepo do valor estratgico de TI, e a TI
aprendeu mais sobre as presses competitivas que o negcio tem de suportar,
conseqentemente a SOA proporciona uma melhor e um maior alinhamento entre TI e
negcio [GRUMAN, 2007].
O negcio precisa de um conjunto de servios que possa ser reagrupado, que
resulta um novo processo de negocio que suporta novos produtos ou servios. E SOA
permite publicar estes servios e frameworks coerentes para que eles possam ser
governados e compostos em aplicaes.
Para uma anlise e estudo de caso ser apresentado algumas possveis
maneiras de implementar SOA baseando em empresas que aceitaram a divulgao de seus
processos e metodologia pelo pesquisador Gruman(2007) na revista CIO, estas empresas
so: Comcast; Leapflog Enterprise ; United Airline; Thoman Financial e Jabil Circuit.
6.1 Comcast
Quando uma empresa decide adotar a abordagem SOA, tentador comear a
comprar uma ESB (Barramento de servio empresarial), registros e outras ferramentas.
Mas o principal valor da SOA esquecido ou colocado de lado como: o alinhamento entre
as aplicaes que so criadas e implementadas e os processos de negcio que elas
executam, segundo Adler11 citado por Gruman(2007).
Comear 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 atrs, resistimos tentao 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 alm de estabelecer framework,
ela tem o papel importante em identificar onde existe redundncia de processos de negcio
11

Tom Adler gerente snior de arquitetura de aplicaes e governana de TI da Comcast.

43

e aplicaes. Isso torna fundamental para explicar o motivo da adeso 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
domnio comum, o prximo passo foi desenvolver o framework de governana para
criao e a implementao de servio. Somente os servios que passam pelos requisitos da
governana so acrescentados ao registro de servios e disponibilizados para reutilizao,
isto permite mostrar a existncia de um servio e guia para uma adoo certa das polticas
e procedimentos.
Aps a implantao Adler, citado por Gruman (2007), percebeu e afirma que a
Comcast deveria ter desenvolvido um modelo de servio de dados comum depois de
definir a arquitetura. Sem servios de dados padres para acessar informao corporativa e
gerenciar interaes entre sistemas, os desenvolvedores acabaram projetando seus servios
para executar o trabalho de diferentes maneiras. O que geraram inconsistncias, quebrando
a promessa de SOA de possibilitar uma mix fcil de componentes de servios. E o preo
disso foi, posteriormente, ter que refazer alguns servios 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 questo tecnolgica. A
Comcast no partiu da viso de que SOA significa usar web servies e aplicou o conceito
SOA a todos os seus esforos, no apenas aos que eram claramente capacitado para web.
Um web service simplesmente mais uma maneira de expor um servio, um detalhe de
implementao. Adler citado por Gruman (2007).
Segundo Gruman (2007) a empresa tem que adaptar a necessidade de negcios
que mudam e as oportunidades tecnolgicas. importante rever a arquitetura de referncia
constantemente para que ela no se transforme em uma camisa-de-fora ou simplesmente
em um documento que todos ignoram; em qualquer um dos casos a empresa perderia os
benefcios de SOA. Um perodo sugerido uma vistoria mensalmente, mesmo no fazendo
nenhuma alterao neste perodo.

44

6.2 Leapfrog Enterprise.

O problema das aplicaes desenvolvidas por grupo desenvolvedores de TI
diferentes atingiu a Leapfrog Enterprise no incio de 2007 quando tentou trazer para um
sistema comum em um portal web, solicitado por um fabricante de brinquedos educativos a
disponibilizar suas diversas aplicaes para fornecedores e clientes de uma maneira
consistente, com o objetivo de melhor se beneficiar do comrcio e das transaes na
internet. A Leapfrog no viu alternativa e decidiu que precisava de uma nova maneira de
desenvolver aplicaes, partiu para uma iniciativa SOA que est comeando dar bons
frutos, segundo Ciurana12 citado por Gruman (2007).
A Leapfrog tinha muitos objetivos comuns a uma tpica iniciativa SOA, queria
uma maior reutilizao de cdigo, desenvolvimento mais veloz e integrao mais fcil.
Mas a empresa no queria limitar a iniciativa SOA uma mudana da guarda de ferramentas
de desenvolvimento e plataformas de integrao.
Ao contrrio a Leapfrog queria dispensar seus desenvolvedores de se submeter
idia de melhores prticas de uma plataforma, mas queria que os mesmos focassem na
funcionalidade das aplicaes e utilizassem a melhor e mais adequada tecnologia para cada
trabalho. Atualmente os desenvolvedores da Leapfrog utiliza uma miscelnea de Java 5 e 6
, C# e web service com diversas bibliotecas de terceiros.
Segundo Gruman (2007), Ciurana tambm no quis obrigar os desenvolvedores a
usar o mesmo transporte, segundo ele o tipo de transporte no 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 mnimo possvel a
implementao de servios, 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 cmodo. E
com uso do ESB Mule, eles no precisam se preocupar como o que h em uma pilha de
SOAP especfica e qual IDE esto utilizando.
A empresa pde adotar esta abordagem por causa do foco em integrar aplicaes
observa, Ciurana.

12

Eugene Ciurana diretor de infra-estrutura de sistemas da Leapfrog

45

A maior parte da integrao est acontecendo no nivel da aplicao, ou seja,

aplicaes se comunicando com outras aplicaes, portanto, aplicaes 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 adoo na Leapfrog e tambm 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 aplicaes em sistemas internos com ERP, ActiveDirectory e data
warehousing, e outro para aplicaes de contato com o cliente baseadas na web, como a
aplicao de autogerenciamento de contas dos clientes e os games on-line que oferece aos
clientes [GRUMAN, 2007]. Isso no s traz um limite natural para gerenciamento de
segurana e acesso, como tambm prov capacidade mutua de backup, j que cada ESB
pode assumir no lugar do outro, se necessrio.
A leapfrog teve que criar um esquema comum de nomeao de servio para que
os servios pudessem executar em ambos ESBs, mas isso um pequeno preo a pagar pela
liberdade do ESB, diz Ciurana [GRUMAN,2007].
6.3 United Arline
As premissas bsicas de SOA requer que as funes transacionais distintas sejam
construdas em blocos, para que possam ser recombinadas quantas vezes for necessria.
Entretanto, muitas tarefas de negcio no so to passveis de decomposio, apoiando-se
em seqncias especificas de eventos.
As companhias areas so um exemplo clssico de conjunto de processos
baseado em eventos e, normalmente, tm 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 tm seu lugar Cidambi13 citado por
Gruman (2007).
As companhias areas possuem sistemas de transao, como reservar passagens e
marcar assentos, no apenas sistemas baseados em eventos, como despachar caminhes de
combustvel quando um avio aterrissa ou atualizar o painel de aviso de chegadas de vos.
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 incio a uma implementao SOA
para lidar com os web services modernos usados no web site united.com. Entretanto estes
dois ambientes so bastantes diferentes e existiam paralelamente [GRUMAN,2007].
Mas isso est comeando a mudar medida que a empresa agrega servios de
transaes s suas operaes internas, por exemplo, informar aos representantes de
servios ao cliente atravs 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 funcionrios para os diversos
portes de cada aeroporto. Isso coloca web services nos mesmos ambientes que os
processos baseados em eventos, fazendo com que a companhia area inicie uma
implementao SOA para alm do programa united.com. Cidambi citado por Gruman
(2007).
O desafio da United projetar e implementar servios na companhia sabendo que
a mesma possui e necessita das duas arquiteturas e podendo tratar como entidade distintas.
Exemplo um vo cancelado (um evento) tambm tem implicaes para os sistemas de
transao (remarcar vos de passageiros, atualizarem ferramentas de pesquisas de status de
vos na web ou emitir vouchers de crditos). Muitos processos tm um componente de
evento e um componente de transao: os representantes de servios ao cliente, obtm a
programao do dia em sistema de transao, mas mudanas de status de avies devido o
cancelamento, atrasos por condies climticas e coisas do gnero tornam essas
programaes confusas muito rapidamente, sendo assim o sistema baseado em eventos
rastreia os status dos avies e o sistema de transao de programao atualiza as
atribuies da equipe ao consultar este status periodicamente e os monitores de exibio
dos horrios de vos empregam o mesmo processo [GRUMAN,2007]. J o sistema de
mensagem foi o maior desafio, os ESBs no utilizam padres fora dos padres web
services, afirma Cidambi citador por Gruman (2007). O modo de lidar com servios
baseados em eventos so obscuros e varia conforme o produto ou ferramenta. Mas
Cidambi valoriza o uso de ESBs para SOA e EDA porque eles lidam com mensagem,
transformaes 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 tambm a
companhia decidiu usar um broker de integrao IBM webSphere como plataforma de
mensagem orientada para publicao/assinatura para servios baseado em eventos,
programando eventos conforme o necessrios e suportando quaisquer transformaes entre
servios, essencialmente atuando como um ESB EDA. Para o transporte foram escolhidas
as aplicaes J2EE existentes que so bastante orientadas a mensagem. E todas JMS como
padro de mensagem ao invs de web services.
Para servios 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 tambm para evitar esforo com integrao, j
que o Aqualogic roda sobre o WebLogic e a IDE eclipse, explica Cidambi.
Outra dificuldade que Cidambi enfrenta a falta de esquemas XML padres para
EDA, fazendo com que a transferncia de mensagens entre servios EDA e SOA seja mais
complexa e demande um nmero maior de desenvolvedores.
6.4 Thomson Financial
Muitas empresa pensam em implementar SOA porque ela promete deixar o
desenvolvimento mais rpido. Mas alguns desenvolvedores descobriram que um elemento
chave da govenana de servio, na realidade pode tornar mais lento o desenvolvimento,
tirando a velocidade prometida, segundo Miteski citado por Gruman (2007).
Para ser considerado um de produo empresarial, um servio precisa estar
em conformidade com diversas metodologias e polticas, muitas so bastante rgidas: os
nomes de elementos XML no podem ser abreviados e tm que ser palavras de
dicionrios, por exemplo. Alguns itens, como nomes e senhas de usurios, no podem ser
hard-coded. Miteski citado por Gruman(2007).
A Thomson Financial tem milhares de servios 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 no importa a granularidade, todo servio passa por
este processo, s ento ele entrado no registro de servios. Da mesma forma, a
conformidade de servios alterados tem que ser avaliada antes que a nova verso seja
48

registrada e disponibilizada para uso em produo, sendo assim o departamento de

arquitetura da financial esta constantemente em gargalo [GRUMAN,2007].
Reduzir os requitos de compliance no era uma opo, dada natureza critica
das aplicaes envolvidas, como os servios de single sign-on, web services que fornecem
informaes sobre o mercado financeiro para analistas e empresas, e servios de analises
e graficos financeiros baseados na web e acessados atravs do Microsoft Office. Miteski
citado por Gruman (2007).
A soluo da Thomson para o problema de workload de conformidade era
recorrer automao, utilizando ferramentas de avaliao de polticas da weblayer.
Segundo Mitevski, as ferramentas so mais eficientes e no deixam passar violaes.
Levou algum tempo para criar as polticas 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
polticas-chaves por parte dos desenvolvedores ou ambigidade na arquitetura, observa
Mitevski, esta metodologia ajuda a mostrar o que pode ser feito melhor, e quais polticas
precisam ser ajustada.
Mitevski descobriu que a maioria das violaes acontecem porque os
desenvolvedores tomam atalhos. Os arquitetos tambm decidem quando abrir excees aos
desenvolvedores por qualquer violao conformidade, algo que acontece raramente. As
excees so anotadas no registro para conhecimento de outros usurios.
Na Thomson Financial, os resultados da automao de conformidade dos servios
so surpreendentes. Segundo Mitevski, antes para colocar um servio em atividade, eram
necessrias 20 pessoas em um processo altamente orquestrado em vrios grupos. Agora
uma pessoa o suficiente, comemora Mitevski [GRUMAN,2007].
6.5 Jabil Circuit.
Uma empresa focada em servios de manufatura tem que enfrentar uma grande
empreitada de integrao do cliente, por exemplo, sistemas de billing, previso e entrada
de pedidos e os muitos sistemas utilizados por seus clientes. Mas muito difcil gerenciar
toda esta comunicao ponto-a-ponto medida que a base de clientes crescem e evoluem
os prprios sistemas. Devido a esta evoluo muitos fabricantes migraram para
fornecedores de hubs de transaes, conhecido como VANs. Cada fornecedor e cliente se
49

preocupam apenas com uma conexo 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 no so suportados por VANs padres. A jabil Circuit, fabricante de
produtos eletrnicos personalizados, enfrentou este dilema da maneira mais difcil:
manter manualmente todas as interfaces e aplicaes personalizadas. Gilvin citado por
Gruman (2007).
A Jabil tem mais de cinco mil parceiros comerciais e era possvel lidar com a
maioria deles atravs da abordagem de VAN. Mas 50 clientes precisam de mecanismos de
comunicao ou processo de negcio especial para os quais a Sterling Commerce VAN
havia sido projetada. Com freqncia, havia vrias destas conexes personalizadas para
cada cliente, aumentando o esforo e algumas precisam mudar, lembra Gilvin.
Baseado nestes altos esforos, ento a Jabil adotou o princpio SOA para
substituir a maioria destas conexes personalizadas por conexes baseadas em servios que
possibilitam a reutilizao de funes comuns.
O primeiro passo foi separar os processos de negcio, gerenciamento do pedido
at o pagamento, previso e estoque em consignao. Por exemplo: os processos de
comunicao. A Jabil agora tem servios padres para a maioria dos mecanismos de
comunicao em uso, como AS1, AS2 e FTP, e servios separados de tratamento de dados,
para os formatos XML, flat-file, Excel e SAP iDocs [GRUMAN,2007].
A empresa compe o servio de comunicao, o servio de tratamento de dados e
o servio de negcio apropriado para cada um destes clientes, usando tabelas e metadados
para automatizar a composio na maioria dos casos. Em alguns casos, os clientes utilizam
mais de um mecanismo, talvez de acordo com o departamento em questo, e as tabelas do
conta destes mltiplos mecanismos, diz Gilvin.
Em alguns casos, requisitos especiais no podem ser satisfeitos atravs da
combinao de servios. Portanto, a Jabil ainda tem algumas integraes one-off para
manter. Ms, portanto, a empresa pode usar a abordagem SOA para parte da integrao. Os
certificados para validao de XML e SSL, por exemplo, no podem ser tratados como
servios padres, mas a Jabil pode compor os servios de comunicao e negcio
apropriados com um servio de tratamento de dados hard-wired, mantendo os benefcios
14

Lowel Gilvin gerente de comrcio eletrnico da empresa Jabil Circuit.

50

de reutilizao e consistncia de SOA em dois dos trs aspectos da integrao, segundo

Gilvin.
Segundo Gilvin, no gerenciamento das mensagens o ESB foi substitudo por um
registro para gerenciar o repositrio de servios ou um ambiente de desenvolvimento
orientado a SOA para desenvolver os servios, a Jabil emprega o Gentran Intregation Sute
da Sterling Commerce para as trs finalidades. O pacote foi projetado para interaes do
supply-chain, justamente o que a empresa esta tentando gerenciar. Este escopo limitado
permite que a Jabil se apie na arquitetura embutida do conjunto de ferramentas, ao
contrario de criar a sua prpria e com isso diminuiu o conjunto de processos padres.
[GRUMAN,2007].

51

7 Concluso.
O contedo deste trabalho deixa transparente que SOA no uma inveno, mas
sim um paradigma que junta os conceitos e as prticas existentes. possvel dizer que
SOA a juno da capacidade intelectual mais o pragmatismo dos sistemas distribudos e
que as pessoas claramente tem o papel de grande importncia, pois so elas que fazem o
com que os processos de negcios, os investimentos acertados aliado ousadia e coragem,
proporcionarem resultados, retorno sobre investimento em uma corporao ou empresa.
Sendo assim, muito antes de falar de tecnologia, SOA deve ser visualizado como um
processo de modernizao, onde a empresa deve possuir uma base slida para suportar as
mudanas exigidas pelo mercado.
Como em todas outras mudanas, SOA tambm no diferente. No se pode
apenas visualizar os benefcios para sua implementao e adoo, necessrio um bom
estudo de caso, um levantamento de requisito preciso e uma boa anlise 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 Aplicaes 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 elegncia 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 Prtica: a arte da modelagem de sistemas distribudos. Jacar:
Alta Books, 2008.
MUNDO JAVA. Tendncias 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: Frum 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 Cincia Moderna, 2008.
RECKZIEGEL, M. Descrevendo, descobrindo e Integrando Web Services. In: Portal
Imaster.
(http://www.imasters.com.br/artigo/4474/webservices/descrevendo_descobrindo_e_integra
ndo_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 enciclopdia Livre. 2008.
(http://pt.wikipedia.org/wiki/Front-end) data da ltima consulta jun. 2008.
WIKIPEDIA. Middleware. In: A enciclopdia 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 padres 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