Este documento discute a aplicação da arquitetura orientada a serviços em um sistema de gestão de fluxo de caixa. Ele apresenta os conceitos-chave da arquitetura orientada a serviços e discute como ela pode melhorar a integração entre sistemas legados e atender às necessidades de negócios em evolução. O documento também descreve um estudo de caso de implementação desses conceitos em um sistema real de fluxo de caixa.

1. Estudo da aplicação da arquitetura orientada a serviços em um sistema de
gestão de fluxo de caixa
Glauco Vinicius Argentino de Oliveira1
Walter Mourão2
RESUMO
Muitas organizações possuem dificuldades em realizar o controle efetivo de sua
informação, uma vez que esta se encontra fragmentada nos diversos sistemas de
informação existentes e sem integração. Esse cenário acaba acarretando o atraso
dos processos de tomada de decisão, principalmente por parte da alta gerência.
Neste cenário a arquitetura orientada a serviços é uma abordagem de
desenvolvimento de sistemas de informação corporativos que busca manter o foco
nos processos de negócio, implementando-os como serviços reutilizáveis e
interoperáveis. Esse trabalho tem por objetivo analisar a experiência da
implementação de alguns conceitos da arquitetura orientada a serviços em sistema
de gestão de fluxo de caixa através da realização de um estudo de caso. No
decorrer desse artigo serão definidos os principais conceitos relacionados á esse
estilo arquitetural, compreendidas as dificuldades de integração com sistemas
legados e levantados aspectos importantes a serem observados durante a adoção
desse paradigma.
Palavras-chave: integração de sistemas, arquitetura de software, arquitetura
orientada a serviços.
1
Analista desenvolvedor da SQUADRA Tecnologia em Software LTDA e aluno do curso superior de
Tecnologia em Sistemas para Internet do Centro Universitário de Belo Horizonte.
Email: gl4uc0@gmail.com.
2
Especialista em melhoria de processo de software e professor do curso superior de Tecnologia em
Sistemas para Internet do Centro Universitário de Belo Horizonte.
Email: walter.mourao@gmail.com.

2. 2
1. INTRODUÇÃO
Em geral, as empresas investem muito dinheiro em software e para que obtenham
um retorno sobre investimento esse software deve ser utilizado por vários anos. No
entanto com o passar do tempo os usuários exigem cada vez mais dos sistemas de
informação, inclusive dos sistemas legados: interfaces gráficas, tempo de resposta
pequeno, extração em tempo real de informações gerenciais, etc. (SANTOS, 2004).
Tipicamente os sistemas legados são grandes, complexos e difíceis de lidar pelo
fato de que muitos processos de negócios foram encapsulados em lógicas de
aplicação no decorrer dos anos (BENNETT, 1995). Esses sistemas acabaram se
transformando no repositório da experiência e do conhecimento das organizações,
tornando-se vitais para a continuidade de seus negócios (SANTOS, 2004, p.6).
As diversas “ondas tecnológicas” pelas quais o mercado passou nos últimos anos,
promoveram a heterogeneidade corporativa (Figura 1). Em grandes corporações é
possível encontrar inúmeros sistemas de informação sendo executados em múltiplas
arquiteturas. Muitos desses sistemas não possuem integração com os demais,
convertendo-se então em verdadeiras “ilhas de informação”. Essa falta de integração
entre os ativos de Tecnologia da Informação (TI) é um desafio que as organizações
enfrentam quando tentam se manter competitivas e crescendo (MICROSOFT, 2006).

3. 3
Figura 1 – Representação da heterogeneidade dos sistemas corporativos e da integração “ponto-a-
ponto”.
Fonte: Adaptado da obra de (JOSSUTIS, 2008, p.14).
Nesse contexto, em que é necessário promover a integração dos diversos sistemas
de informação heterogêneos, a arquitetura orientada a serviços (SOA3) ganha
destaque como uma abordagem capaz de promover o melhor alinhamento do
departamento de TI com as necessidades da empresa, de forma a responder melhor
às mudanças.
A arquitetura orientada a serviços é um estilo de arquitetura de software com foco na
distribuição do processamento através da criação e publicação de serviços
reutilizáveis, flexíveis e interoperáveis. Esses serviços são funcionalidades
específicas presentes nas aplicações corporativas e que dizem respeito ao negócio
da empresa, e que podem ser disponibilizados para todas as demais aplicações de
3
SOA é a sigla para Service Oriented Architecture ou Arquitetura Orientada a Serviços.

4. 4
modo a facilitar e unificar o processo de desenvolvimento de software (MICROSOFT,
2006).
Os sistemas de informação, que utilizam a arquitetura orientada a serviços, se
organizam de tal forma que passam a ser criados a partir dos componentes que
executam funções discretas de negócio. Estes componentes, denominados
“serviços”, podem ser distribuídos e ajustados em um novo processo de negócio
assim que necessário. O objetivo é permitir às empresas realizar negócios e obter
vantagens tecnológicas por meio da combinação e inovação de processos,
governança eficaz e estratégia de tecnologia, as quais giram em torno da definição e
reutilização de serviços (SOUZA JÚNIOR et al, 2007).
Segundo (IBM, 2005), a arquitetura orientada a serviços oferece aos negócios os
seguintes benefícios:
 Permite maior agilidade na realização dos processos de negócios;
 Habilita as organizações a transcender seus limites;
 Reduz o tempo dos ciclos de desenvolvimento de software;
Juntamente com os benefícios para o negócio, o departamento de TI pode colher os
seguintes benefícios:
 Gerar serviços apenas uma vez e utilizá-los freqüentemente;
 Promover a consistência dos processos de negócio;
 Padronizar a integração e a redução da complexidade das soluções de
software;
De maneira geral, observa-se que a adoção da arquitetura orientada a serviços
ainda é baixa, bem como a quantidade de material científico publicado no idioma
português a respeito do assunto.
O principal objetivo desse trabalho é analisar uma experiência da implementação
dos conceitos da arquitetura orientada a serviços em sistema de informação do
mundo real. Para tanto, os objetivos secundários são:

5. 5
 Definir os principais conceitos relacionados à Arquitetura Orientada a
Serviços;
 Compreender as dificuldades da integração de sistemas legados;
 Identificar aspectos importantes a serem observados durante a adoção de
SOA em uma organização;
A pretensão desse trabalho é fornecer uma ferramenta de consulta para suporte a
decisões da utilização ou grau de utilização da arquitetura orientada a serviços.
Será realizado um estudo de caso da implementação de um sistema de informação
que utiliza conceitos da arquitetura orientada a serviços. Nesse estudo de caso
serão identificadas as principais dificuldades observadas durante a implementação
bem como um conjunto de boas práticas identificadas.
O estudo de caso foi selecionado como metodologia para o desenvolvimento desse
trabalho pelo fato de ser um tipo de pesquisa qualitativa que visa compreender e
evidenciar o “como” e “porque” de um determinado cenário. É um tipo de
investigação a respeito de uma situação específica que procura descobrir sua
essência e características e que possui um forte cunho descritivo, sem a
interferência do pesquisador sobre a situação.
O trabalho de pesquisa consistiu em uma série de reuniões presenciais com os
profissionais envolvidos no processo de desenvolvimento. Houve uma intensa
pesquisa documental de todos os artefatos gerados na fase de concepção,
elaboração e construção do projeto.
Esse projeto foi escolhido para a realização desse estudo de caso pelo fato de
incorporar alguns dos princípios da arquitetura orientada a serviços e ser um
primeiro passo para a adoção desse estilo arquitetural por toda a empresa.

6. 6
2. MARCO TEÓRICO
A arquitetura orientada a serviços consiste em três elementos principais que serão
apresentados em maiores detalhes no decorrer do artigo:
 Serviços;
 Infra-estrutura;
 Políticas e processos.
2.1 ARQUITETURA DE SOFTWARE
Para compreender o conceito de arquitetura orientada a serviços é necessário
compreender o que é a arquitetura de software e qual a sua importância em um
projeto de software.
Em sua obra, Bass, Clements e Kazman definem a arquitetura de software como
sendo a estrutura de um sistema computacional, que abrange os componentes de
software que compõem esse sistema, suas propriedades visíveis externamente e o
relacionamento entre eles.
Pressman ainda enfatiza que a arquitetura não é o software operacional, mas sim
uma representação que permite ao engenheiro de software:
 Analisar a aderência do desenho aos requisitos levantados junto ao cliente;
 Considerar alternativas arquiteturais em um estágio no qual as alterações no
desenho ainda são relativamente simples;
 Minimizar os riscos associados á construção de software;
Com base na obra de Bass, Clements e Kazman, Pressman elenca três principais
razões para justificar a arquitetura de software:

7. 7
 As representações da arquitetura de software são uma forma de melhorar a
comunicação entre as partes interessadas (stakeholders) no desenvolvimento
do software.
 A arquitetura destaca as decisões de desenho que terão um impacto profundo
em todo o trabalho consecutivo da engenharia de software, e no sucesso final
do software.
 A arquitetura representa um modelo de como um software é estruturado e
como seus componentes trabalham juntos.
2.2 ARQUITETURA ORIENTADA A SERVIÇOS
A arquitetura orientada a serviços é um paradigma que tem como principal objetivo a
exposição e reuso intenso de serviços, componentes de software que executam
tarefas específicas relacionadas ao negócio, de maneira pouco acoplada e
interoperável, para que em médio prazo a tarefa de desenvolver uma aplicação seja
primordialmente a tarefa de compor e coordenar os serviços já existentes
(MACHADO, 2004).
Josuttis afirma que a arquitetura orientada a serviços lida muito bem com
características difíceis e conhecidas dos grandes sistemas:
 Sistemas distribuídos;
 Diferentes proprietários;
 Heterogeneidade;
As características da arquitetura orientada a serviços que permite lidar muito bem
com as características dos grandes sistemas, citadas anteriormente, são:
 Serviços: A arquitetura orientada a serviços objetiva abstrair concentrando-se
no aspecto corporativo do problema. Um serviço é então, uma representação
da TI de alguma funcionalidade de negócio. O objetivo da arquitetura
orientada a serviços é estruturar grandes sistemas distribuídos baseados em
abstração das regras e funções de negócio;

8. 8
 Interoperabilidade: A interoperabilidade não é um conceito novo e existia
muito antes do aparecimento da arquitetura orientada a serviços juntamente
com a idéia de EAI (Enterprise Application Integration). Entretanto, na
arquitetura orientada a serviços, a interoperabilidade é quem guia a
implementação das funcionalidades de negócio (serviços);
 Acoplamento fraco: Acoplamento fraco consiste em minimizar as
dependências de modo a aumentar a flexibilidade, escalabilidade e tolerância
às falhas;
Machado ainda apresenta algumas características relevantes presentes em grande
parte das aplicações e frameworks orientados a serviços. As características
consideradas relevantes são:
 Reuso “caixa-preta”: Diz respeito à capacidade de extensão das
funcionalidades através da descrição de interfaces ou contratos bem definidos
que devem ser respeitados;
 Distribuição: Um sistema baseado na uma arquitetura orientada a serviços é
tipicamente um sistema cooperativo aberto. Em um sistema cooperativo
aberto, novas entidades podem dinamicamente passar a compor o sistema,
deixar de existir ou ainda evoluir, sendo que essas entidades podem estar
localizadas em máquinas distintas;
 Heterogeneidade Ambiental: Em virtude da distribuição, existe a
necessidade de que sistemas baseados na arquitetura orientada a serviços
ofereçam suporte a ambientes heterogêneos. Em geral os componentes dos
sistemas (serviços) estão executando em máquinas distintas, e precisam se
comunicar de alguma forma;
 Composição: O ideal perseguido é a capacidade de compor ou recompor
aplicações sem tocar em código escrito e devidamente testado;
 Coordenação: Está intimamente ligada com a sincronização, ordenação e
temporização da execução dos serviços. Na indústria, à coordenação está
mais relacionada a modelagem de processos de negócios (BPM – Business
Process Management), onde a linguagem usada tenta descrever intimamente
como funciona o processo da corporação;

9. 9
 Dinamismo e Adaptabilidade: Aplicações orientadas a serviços conseguem
se adaptar às mudanças de requerimentos com facilidade. Os serviços podem
entrar e sair do sistema em tempo de execução, tipicamente se comunicando
com o registro de serviços através de mensagens de publicação ou de
remoção. Além disso, geralmente os sistemas nunca fazem referência direta
ao serviço e sim a uma interface para o serviço, possibilitando dinamismo;
 Sincronia: A troca de mensagens, seu modo de transmissão e a semântica
são partes fundamentais em sistemas distribuídos, pois são a única maneira
que os componentes possuem de se comunicar e sincronizar suas ações;
2.3. SERVIÇOS E PROCESSOS DE NEGÓCIO
Como dito anteriormente, a arquitetura orientada a serviços é focada nos processos
de negócio. Um processo do negócio pode ser automatizado por meio de sistemas
de informação visando realizá-lo com maior rapidez, menor quantidade de erros,
menor custo e maior qualidade. Esse processo pode ser executado com um ou mais
passos e esses passos podem ser executados em sistemas diferentes.
É possível desmembrar um processo de negócio em passos menores e mais
concretos. A Figura 2 fornece uma representação possível desse conceito, no
entanto, deve-se ter em mente que o número exato de camadas e terminologia
podem variar de acordo com o ambiente.

10. 10
Figura 2 – Representação da hierarquia de um processo de negócio.
Fonte: Adaptado da obra de (JOSUTTIS, 2008, p.74).
O principal objetivo de um serviço é representar um passo natural da funcionalidade
de negócio. Sendo assim, um serviço pode ser definido como uma tarefa repetitiva e
específica dentro de um processo de negócio (IBM, 2005), uma peça independente
de funcionalidade que pode ser descoberta na rede, e que descreve o que ela pode
fazer e como pode se interagir com ela (MICROSOFT, 2006).
Esses serviços podem ser implementados e consumidos em uma única máquina,
distribuídos através de um conjunto de computadores ou uma rede local, ou através
de redes corporativas (IBM, 2005).
Pelo fato desses serviços serem implementados tendo em vista o negócio, as
pessoas de negócio deveriam ser capazes de entender o que um serviço faz
(JOSUTTIS, 2008). A principal conseqüência dessa abordagem é que neste nível de
abstração os detalhes específicos da plataforma não importam.

11. 11
Muitas definições da arquitetura orientada a serviço que foram encontradas no
decorrer do desenvolvimento desse artigo, afirmam que a implementação dos
serviços deve ser realizada utilizando-se os XML Web Services. Muitos até
confundem a arquitetura orientada a serviços com essa tecnologia. Os XML Web
Services são apenas uma maneira para implementar a arquitetura orientada a
serviços, contudo, o conceito dessa arquitetura não está vinculado a nenhuma
tecnologia específica.
2.4. ENTERPRISE SERVICE BUS
O ESB (Enterprise Service Bus ou Barramento de Serviços Corporativos) é parte da
infra-estrutura da arquitetura orientada a serviços e provê um modo dos
consumidores invocarem os serviços ofertados pelos fornecedores.
A Figura 3 ilustra a utilização do ESB em um cenário de SOA federativa ou em rede.
Esse cenário ocorre quando existem serviços básicos (funcionalidade discretas) e os
compostos (serviços compostos por outros serviços). Esse estágio introduz uma
camada adicional para os serviços,denominada camada de orquestração.

12. 12
Figura 3 – Representação da interação entre serviços, orquestração de serviços, ESB e consumidor
de serviço.
Fonte: JOSUTTIS, 2008, p.62.
Dentre as responsabilidades atribuídas a um ESB e citadas por (JOSUTTIS, 2008)
estão:
 Prover conectividade: Possibilitar que um consumidor converse com um
fornecedor sem conhecer necessariamente sua localização;
 Transformação de dados: Por integrar diferentes plataformas e linguagens
de programação, uma parte fundamental é a transformação de dados;
 Roteamento inteligente: Prover uma maneira para enviar uma chamada de
serviço do consumidor para o fornecedor e depois enviar uma resposta do
fornecedor para o consumidor;
 Lidar com segurança: Restringir o modo como os consumidores invocam os
serviços e vêem os resultados;
 Lidar com confiabilidade: Garantir que uma mensagem enviada por um
consumidor ou uma resposta enviada por um fornecedor serão entregues;
 Gerenciamento dos serviços: Mais cedo ou mais tarde surgirão dúvidas
referentes à como gerenciar todos os serviços disponíveis. Isso abrange
definições de como o consumidor descobrirá um serviço já existente e onde

13. 13
informações mais detalhadas do serviço podem ser encontradas, por
exemplo;
 Monitoramento e logging: Registra qual é o cliente que está chamando
determinado serviço e quanto tempo leva uma chamada específica;
2.5. BUSINESS PROCESS MANAGEMENT
O Gerenciamento de Processos de Negócios (BPM) freqüentemente é relacionado à
arquitetura orientada a serviços. O BPM é uma disciplina de gerenciamento que
combina a gestão de negócio com a TI, buscando a melhoria dos processos de
negócio através da utilização de métodos e ferramentas para modelar, publicar,
controlar e analisar os diversos processos de negócio, de modo a permitir que as
organizações alcancem seus objetivos (MICROSOFT, 2006).
O BPM promove a agilidade organizacional e suporta os esforços dos funcionários
para o direcionamento de mudanças no processo e rápida inovação. Para isso, o
BPM suporta o alinhamento do TI e das atividades de negócios dentro da empresa e
fora dela, com parceiros comerciais e fornecedores (MICROSOFT, 2006).
Um processo de negócio pode ser caracterizado como um conjunto de tarefas
que envolvem pessoas e recursos para que possa se atingir um objetivo bem
definido. Como resultado deste, é gerado um produto ou serviço que vai ao
encontro dos desejos dos clientes.
Os processos de negócios podem ser estruturados ou não, dependendo do grau de
mobilidade dos passos subjacentes, ou seja: automatizados ou mutáveis,
geralmente executados apenas por pessoas ou por pessoas interagindo com
sistemas. As pessoas são uma parte essencial de quase todos os processos de
negócios – elas direcionam as soluções e as percepções que fazem uma empresa
avançar e, portanto, o objetivo deve ser capacitá-las para criar inovações e serem
mais produtivas (e não uma “reengenharia” de pessoas que as exclua do processo).

14. 14
3. ESTUDO DE CASO
Neste estudo de caso será apresentado um projeto de software em desenvolvimento
para uma grande empresa de engenharia do Brasil. Essa empresa atua a mais de
50 anos no mercado de construção pesada no Brasil e no Exterior, desenvolvendo
projetos nos segmentos de construção rodoviária, ferroviária, metroviária, portuária,
hidroelétrica, termoelétrica, petróleo e gás, dutos, saneamento urbano, canais de
irrigação e manutenção industrial onshore4 ou offshore5.
3.1. PROPÓSITO
Esse projeto de software consiste no desenvolvimento de um sistema de gestão do
fluxo de caixa e tem por objetivo melhorar e unificar o processo de fluxo de caixa.
3.2. O PROCESSO DE FLUXO DE CAIXA
O fluxo de caixa pode ser considerado uma demonstração visual das receitas e
despesas distribuídas em uma linha do tempo e consiste na previsão de entradas e
saídas de recursos financeiros em um determinado período. O principal objetivo
dessa previsão financeira é fornecer informações para a tomada de decisões, tais
como:
 Prognosticar as necessidades de captação de recursos financeiros;
 Prever a sobra ou falta de recursos financeiros;
 Aplicar o excedente de caixa em alternativas rentáveis para a empresa.
4
Localizado ou operado em terra.
5
Localizado ou operado no mar.

15. 15
Para montar essa projeção do fluxo de caixa, é necessário levar em consideração os
seguintes dados (Figura 4):
 Entradas: contas a pagar e receber; empréstimos; saldo do caixa;
 Saídas: contas a pagar; custos fixos (despesas gerais de administração);
pagamentos de empréstimos; compras a vista;
Figura 4 – Representação do processo de fluxo de caixa.
Fonte: Squadra Tecnologia.
O fluxo de caixa é considerado um dos principais instrumentos de análise e
avaliação de uma empresa, proporcionando ao administrador uma visão futura dos
recursos financeiros da empresa, integrando o caixa, as contas correntes em
bancos, contas de aplicações, receitas, despesas e as previsões.
Essa projeção pode ser realizada mês a mês, trimestre a trimestre ano a ano ou até
mesmo em bases diárias.
7.3. CENÁRIO ATUAL
Atualmente, essa empresa convive com os seguintes problemas referentes ao fluxo
de caixa:
 É dependente de suas filiais no que tange aos processos financeiros;
 Possui dificuldades na captação de dados das fontes heterogêneas;
 Possui dificuldade na realização do processo de previsão de caixa;

16. 16
Todos esses problemas contribuem para o aumento da dificuldade em antever com
assertividade a sobra e a falta de caixa em médio prazo, um grande volume de
trabalho e retrabalho e a dificuldade em captar e aplicar recursos no mercado de
maneira mais adequada.
ERP (Enterprise Resource Planning) são sistemas de informação desenvolvidos
para integrar dados, processos e departamentos de uma organização possibilitando
a automação e armazenamento de todas as informações em um único sistema.
Essa integração pode ser vista sob a perspectiva funcional (sistemas de: finanças,
contabilidade, recursos humanos, fabricação, marketing, vendas, compras, etc) e
sob a perspectiva sistêmica (sistema de processamento de transações, sistemas de
informações gerenciais, sistemas de apoio a decisão, etc).
Com o intuito de auxiliar na gestão do fluxo de caixa, um ERP6, um sistema legado,
que envolve todo o movimento transacional da empresa, é utilizado por algumas
áreas funcionais (Figura 5). Esse ERP foi desenvolvido utilizando-se uma linguagem
chamada 4GL e utiliza banco de dados IBM INFORMIX. Ele é composto por uma
série de módulos, tais como: contas a pagar, contas a receber, suprimentos, etc.
Apesar disso, o controle das previsões financeiras é realizado utilizando-se planilhas
eletrônicas. Para a realização das previsões financeiras, cada área funcional envia
uma planilha com seus dados e a unificação desses dados é realizada
manualmente.
Figura 5 – Representação da composição do ERP Legado.
Fonte: Squadra Tecnologia.
6
Sistemas de informação que integram todos os dados e processos de uma organização em um
único sistema.

17. 17
Buscando modelar e melhorar seus processos de negócio, foi contratada uma
consultoria no ano de 2006. Essa consultoria detectou uma série de pontos a
melhorar, e o projeto de desenvolvimento desse software é um dos passos
propostos para a melhoria do processo de fluxo de caixa.
Durante a fase de concepção desse projeto foram identificadas algumas
características que influenciaram na decisão de utilizar conceitos da arquitetura
orientada a serviço. São eles:
 Extração de dados de um ERP composto por pelo menos 15 módulos;
 Exposição de serviços reutilizáveis que serão consumidos nas próximas
aplicações desenvolvidas por essa empresa;
 Necessidade de promover o “reuso corporativo”;
Existe hoje nessa empresa uma tendência á criação de um ambiente tecnológico
corporativo homogêneo. Para tanto, foi decidido que todos os novos sistemas de
informação deveriam ser desenvolvidos utilizando-se a plataforma Microsoft .NET.
Seguindo essa tendência, a empresa optou pelo desenvolvimento desse novo
sistema de informação utilizando o .NET Framework 2.0.
3.4. SOLUÇÃO PROPOSTA
Tendo em vista os problemas levantados junto ao cliente e apresentados
anteriormente, foi pensada uma arquitetura que promovesse a criação de um novo
sistema de informação para atuar como uma camada acima do legado. Esse novo
sistema de informação tem por objetivo centralizar todos os dados referentes á
gestão do fluxo de caixa (provenientes do ERP Legado) em uma nova base de
dados. Essa base de dados posteriormente será utilizada para a criação de um
sistema de Business Intelligence.
As principais funcionalidades esperadas desse sistema dizem respeito á
possibilidade de criar previsões de caixa de cada uma das áreas funcionais e decidir

18. 18
o fluxo de caixa. Dessa maneira a empresa poderá agir de uma maneira mais
proativa diante dos eventos financeiros.
Com o intuito de possibilitar uma maior flexibilidade nas mudanças e otimizar os
processos de negócio, foi incorporada uma abordagem orientada a processos. O
intuito do BPM é orquestrar o fluxo de chamadas dos serviços e criar serviços
compostos.
Para implementar o BPM foi escolhido o jBPM. jBPM é uma ferramenta de gerência
de processos para o ambiente Java reconhecida pelo mercado. O principal motivo
para sua escolha foi o fato de que o driver de acesso ao banco de dados utilizado
pelo cliente (IBM INFORMIX) possuir uma série de problemas de compatibilidade
com o Microsoft .NET Framework, principalmente no que diz respeito ao suporte á
two phase commit (2PC7). Esse problema não ocorre no ambiente Java e por
consequência no jBPM.
Para a modelagem dos processos de negócio não foi utilizada a linguagem BPEL
(Business Process Execution Language), uma vez que esta mapeia apenas
processos executáveis (sem a interação de seres humanos). Para a modelagem dos
processos de negócio foi utilizada então a linguagem XPDL (XML Process Definitio
Language) que é uma linguagem que permite o mapeamento de processos de
negócio (com a interação de seres humanos).
Assim como o BPM, todos os serviços criados até então foram escritos em Java.
Esses serviços são consumidos por essa aplicação e também expostos para as
demais aplicações como XML Web Services. A utilização dos XML Web Services
deve-se ao fato dessa ser uma tecnologia amplamente suportada atualmente e que
permite a interoperabilidade dos diversos sistemas de informação, sendo
independente da linguagem de programação utilizada e plataforma. Os detalhes
referentes à XML Web Services não são descritos nesse trabalho, uma vez que
7
É uma abordagem para manter a consistência através de múltiplos sistemas. Na primeira fase,
todos os backends são perguntados para confirmar uma mudança solicitada para que na segunda
fase o commit das atualizações normalmente sejam bem sucedido. De acordo com o princípio de
acoplamento fraco, compensação é o termo usando em SOA, no lugar de 2PC.

19. 19
constituem um assunto bastante extenso e não constituem parte essencial da
arquitetura orientada a serviços.
Cabe uma importante observação quanto aos XML Web Services: a simples
utilização destes em um projeto de software, não qualifica o software como orientado
a serviços. Grande parte ou todos os conceitos tratados anteriormente nesse artigo
devem fazer parte da cultura organizacional para que uma solução de software
possa ser denominada realmente como orientada a serviços. A partir disso, tem-se
que XML Web Services são meramente uma forma de se implementar a arquitetura
orientada a serviços, mas não parte essencial dela.
A decisão de expor esses serviços não partiu da equipe de desenvolvimento, mas
sim da empresa. Todos os serviços expostos foram elencados e constituem seus
principais processos de negócio.
O papel dos serviços neste cenário é disponibilizar funcionalidades as quais poderão
ser facilmente acopladas nos processos. Estes serviços têm a característica de
serem focados em objetivo, por este motivo, os serviços são rotinas concisas e com
um escopo bem definido. Isto é feito com o objetivo de não possuírem serviços que
sobreponha funcionalidades que possam estar em outros serviços.
Visando prover conectividade entre a aplicação e os serviços criados, foi
implementado um barramento corporativo de serviços (ESB) pala equipe de
desenvolvimento. Esse barramento não possui todas as funcionalidades previstas
em um barramento adquirido comercialmente, entretanto, atende ás necessidade do
projeto em um primeiro momento. Dentre as funcionalidades ofertadas por esse
componente de software estão:
 Capacidade de prover conectividade entre a aplicação e os serviços;
 Capacidade de rotear as mensagens entre clientes e fornecedores de
serviços;
 Capacidade de interceptar e tratar as mensagens trafegadas;
A função de interceptar e tratar as mensagens tem o objetivo de, se necessário for,
alterar o fluxo da mensagem e/ou o seu conteúdo. Já a função de expor os serviços

20. 20
possibilita que outros sistemas ou subsistemas possam utilizar dos serviços
disponibilizados. Existiu a demanda de um barramento neste cenário devido à
necessidade de integração com sistemas legados, bem como o reaproveitamento de
serviços por outros sistemas.
4. CONCLUSÃO
A arquitetura orientada a serviços é uma abordagem capaz de promover a criação,
exposição e reutilização de vários serviços de negócio, promovendo a produtividade
e a lucratividade no desenvolvimento e manutenção de software. Sua capacidade de
lidar bem com ambientes heterogêneos permite que novos softwares sejam criados,
independente de linguagem de programação ou plataforma, tendo como foco
principal o negócio.
A criação e exposição de serviços oferecem uma série de benefícios, tanto no que
tange à rapidez do desenvolvimento, como na redução de custos e prazos na
distribuição de sistemas. Ela possibilita integração de sistemas de plataformas
diferentes (.NET, J2EE, CORBA), tornando o ambiente corporativo interoperável.
Este estilo arquitetural não introduz nenhum conceito novo. É um paradigma que
reúne os principais conceitos e práticas de integração de sistemas já existentes.
Outro aspecto importante é o fato desse paradigma aceitar a heterogeneidade do
ambiente corporativo, ao contrario de outras abordagens precursoras.
Assim como todo e qualquer paradigma ou tecnologia, a arquitetura orientada a
serviços não deve ser encarada como uma “bala de prata”. Apesar de todas as
vantagens ofertadas pela utilização desse paradigma, deve-se ponderar a respeito
de sua utilização em cada cenário. Esse e um paradigma cujo custo de
implementação pode ser relativamente caro caso o ambiente corporativo seja
homogêneo. Para ambientes homogêneos existem soluções mais simples e de
menor custo.

21. 21
Durante o desenvolvimento desse trabalho foram definidos os principais conceitos
relacionados á arquitetura orientada a serviços, bem como foram apresentados
algumas das dificuldades encontradas na integração de sistemas de informação no
contexto corporativo.
Com base nesse estudo de caso e na experiência da equipe que compõe esse
projeto, que já participou de outros projetos envolvendo EAI e SOA, foram
identificados alguns aspectos importantes a serem observados durante a adoção de
SOA em uma organização:
 Utilização de padrões de mercado: A utilização de muitos padrões em um
mesmo projeto SOA, acarreta no insucesso do consumo dos serviços. Dentre
os padrões mais utilizados atualmente estão:
o WS-I: utilização de tecnologias compatíveis com o padrão de
interoperabilidade de Web Services.
o WS-BPEL: Implementação dos processos executáveis genéricos e
reutilizáveis utilizando BPEL (Business Process Execution Language).
o WSDL: Mecanismo de definição de serviços e as mensagens que um
serviço oferece.
o UDDI: Mecanismo de procura e registro de serviços para promover o
reuso.
o SOAP: Protocolo baseado em HTTP que usa mensageria composta de
XML sobre uma rede.
 Utilização do ESB: O ESB não é um componente essencial em soluções
SOA, desde que o ambiente da empresa não tenha um cenário complexo de
integração. Entretanto na maioria dos casos o ESB é um elemento essencial.
 Aderência aos princípios SOA: Alguns princípios pregados pela arquitetura
centrada em orientação a serviços devem ser seguidos, para garantir as
promessas feitas sobre SOA. São eles:
o Fraco acoplamento:
o Contrato de Interfaces
o Serviços reutilizáveis

22. 22
 Utilização de nomes de negócio para os serviços: Os consumidores dos
serviços são analistas de negócio. Desta forma, os nomes dos serviços
devem usar as suas terminologias e vocabulário para tornar seu significado
mais intuitivo.
 Utilização da abordagem Bottom-Up e Top-Down para elencar os
serviços: A abordagem Bottom-Up investiga o legado da empresa, em
especial, as aplicações escritas antes da adoção da SOA, sobre possíveis
funcionalidades e componentes que possam agregar valor de negócio para as
novas soluções, no formato de serviços.
A Top-Down, especifica processos de negócio que compõem fluxos de dados
e processos, contanto com isso com serviços que possibilitem a correta
execução destes processos. Neste caso, através do desenho do processo,
podem-se descobrir quais serviços serão necessários, e neste caso decide-se
aproveitar o que o legado têm a oferecer (usando um ESB para transformar o
legado em serviços), ou criar o serviço do zero, uma vez identificado que
aquele comportamento jamais foi feito em termos de TI na empresa.
 Criar serviços que tenham operações atômicas: Se um serviço realiza
uma operação transacional de alteração ou exclusão de dados, esta operação
deve poder ser desfeita sem que outros serviços sejam afetados. Quem deve
se preocupar com compensação de transações e estornos deve ser o gestor
do processo BPEL, e não o serviço. Sendo assim, o serviço deve se
preocupar apenas com os seus próprios dados.
 Construir os serviços iterativamente: Tornar os serviços de uma empresa
disponíveis é algo que pode ser feito de maneira incremental. Ë interessante
começar por uma área ou grupo de processos da empresa que traga maior
valor agregado.
No momento do término desse artigo esse projeto ainda estava em andamento (fase
de construção, segundo o RUP8). Entretanto isso não é um empecilho para que o
mesmo seja utilizado como referencial desse trabalho, uma vez que a arquitetura
proposta está bem-definida e mudanças no escopo serão pouco significativas. Para
8
O Rational Unified Process (RUP) é um framework de processos da IBM Rational guiado por casos
de uso, centrado na arquitetura, e que propõe o desenvolvimento de software de modo iterativo e
incremental.

23. 23
trabalhos futuros, espera-se relatar o término desse processo de desenvolvimento e
os passos conseguintes da adoção da arquitetura orientada a serviços por essa
empresa.

24. 24
Study about the application of the service oriented architecture in a cash flow
management system
ABSTRACT
Many corporations has problems in control effectively its information,
once it is fragmented in the several existing information systems without integration.
Such scenario brings delays to reach decisions, mainly caused by the management
team. In this scenario, the Service Oriented Architecture (SOA) is a corporate
information system development approach that aims focus in the business process,
implementing them as reusable and interoperable services.
This work aims to analyse the experience of implementing some service-oriented
architeture concepts in a cash-flow management system, through a case study. I the
course of this article, the main concepts of that architectural style will be related,
since the dificulties of integrating with legacy systems are known, and important
aspects to be watched during the adoption of that paradigm.
Keywords: Systems Integration, Software Architecture, Service Oriented
Architecture

25. 25
REFERÊNCIAS
BASS, CLEMENTS, KAZMAN. Software Architecture in Practice, 2nd edition,
Addison Wesley, 2003, p.44.
BENNETT, K.H. Legacy Systems: Coping With Success, IEEE Software, January
1995, Vol 12, No. 1, pp 19-23
IBM CORPORATION, IBM’s SOA Foundation: An Architectural Introduction and
Overview, November 2005.
IBM CORPORATION, Introduction to the Value and Governance Model of
Service-Oriented Architecture, 2005.
JOSUTTIS, Nicolai M., SOA na prática: A arte de modelar sistemas distribuídos,
AltaBooks, 2008.
MACHADO, João Coutinho, Um Estudo Sobre o Desenvolvimento Orientado a
Serviços, 2004. Trabalho acadêmico – (Tese de Mestrado) – Pontifica Universidade
Católica do Rio de Janeiro, Rio de Janeiro, 2004.
MICROSOFT CORPORATION, Ativando uma “Arquitetura Orientada a Serviços
Realista” na Plataforma Microsoft, Dezembro 2006.
PRESSMAN, Roger. Software Engineering: A Practitioner's Approach, 5th
edition, McGraw-Hill, 2000, p.366-368.
SANTOS, Cássio Rogério Celestino, Gerência de Risco na Modernização de
Sistemas Legados. 2004. Trabalho acadêmico – (Monografia) – Escola Politécnica
da Universidade de São Paulo, São Paulo, 2004, Disponível em:
<http://www.pcs.usp.br/~lucia/teses/CassioSantos.pdf>. Acesso em: 04 mar. 2008.
SOUZA JÚNIOR, Marcílio, CUNHA, Mônica, CAMPOS NETO, João Gabriel,
SANTOS BARROS, Heitor, Implementação de um protótipo para integração
orientada a serviços dos sistemas de informação do CEFET-AL, 2007. Trabalho
acadêmico – (Artigo Científico) – CEFET-AL, Maceió, Alagoas.
`

26. 26
Meus sinceros agradecimentos á minha família pelo apoio,
meus amigos pelo companheirismo e estímulo e meu
orientador por acreditar em meu potencial e por me orientar,
permitindo-me realizar esse trabalho.
Obrigado por me ensinarem com prazer e dedicação parte do
que sei e, o que é mais importante, me ensinarem a aprender
sozinho.