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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.