Estudo da aplicação da arquitetura orientada a serviços em um sistema degestão de fluxo de caixaGlauco Vinicius Argentino ...
21. INTRODUÇÃOEm geral, as empresas investem muito dinheiro em software e para que obtenhamum retorno sobre investimento e...
3Figura 1 – Representação da heterogeneidade dos sistemas corporativos e da integração “ponto-a-ponto”.Fonte: Adaptado da ...
4modo a facilitar e unificar o processo de desenvolvimento de software (MICROSOFT,2006).Os sistemas de informação, que uti...
5      Definir os principais conceitos relacionados à Arquitetura Orientada a       Serviços;      Compreender as dificu...
62. MARCO TEÓRICOA arquitetura orientada a serviços consiste em três elementos principais que serãoapresentados em maiores...
7      As representações da arquitetura de software são uma forma de melhorar a       comunicação entre as partes interes...
8      Interoperabilidade: A interoperabilidade não é um conceito novo e existia       muito antes do aparecimento da arq...
9      Dinamismo e Adaptabilidade: Aplicações orientadas a serviços conseguem       se adaptar às mudanças de requeriment...
10Figura 2 – Representação da hierarquia de um processo de negócio.Fonte: Adaptado da obra de (JOSUTTIS, 2008, p.74).O pri...
11Muitas definições da arquitetura orientada a serviço que foram encontradas nodecorrer do desenvolvimento desse artigo, a...
12Figura 3 – Representação da interação entre serviços, orquestração de serviços, ESB e consumidorde serviço.Fonte: JOSUTT...
13       informações mais detalhadas do serviço podem ser encontradas, por       exemplo;      Monitoramento e logging: R...
143. ESTUDO DE CASONeste estudo de caso será apresentado um projeto de software em desenvolvimentopara uma grande empresa ...
15Para montar essa projeção do fluxo de caixa, é necessário levar em consideração osseguintes dados (Figura 4):      Entr...
16Todos esses problemas contribuem para o aumento da dificuldade em antever comassertividade a sobra e a falta de caixa em...
17Buscando modelar e melhorar seus processos de negócio, foi contratada umaconsultoria no ano de 2006. Essa consultoria de...
18o fluxo de caixa. Dessa maneira a empresa poderá agir de uma maneira maisproativa diante dos eventos financeiros.Com o i...
19constituem um assunto bastante extenso e não constituem parte essencial daarquitetura orientada a serviços.Cabe uma impo...
20possibilita que outros sistemas ou subsistemas possam utilizar dos serviçosdisponibilizados. Existiu a demanda de um bar...
21Durante o desenvolvimento desse trabalho foram definidos os principais conceitosrelacionados á arquitetura orientada a s...
22       Utilização de nomes de negócio para os serviços: Os consumidores dos        serviços são analistas de negócio. D...
23trabalhos futuros, espera-se relatar o término desse processo de desenvolvimento eos passos conseguintes da adoção da ar...
24Study about the application of the service oriented architecture in a cash flowmanagement system                        ...
25                                REFERÊNCIASBASS, CLEMENTS, KAZMAN. Software Architecture in Practice, 2nd edition,Addiso...
26Meus sinceros agradecimentos á minha família pelo apoio,meus amigos pelo companheirismo e estímulo e meuorientador por a...
Upcoming SlideShare
Loading in...5
×

Estudo da aplicação da arquitetura orientada a serviços em um sistema de gestão de fluxo de caixa

2,676

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,676
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
94
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Estudo da aplicação da arquitetura orientada a serviços em um sistema de gestão de fluxo de caixa

  1. 1. Estudo da aplicação da arquitetura orientada a serviços em um sistema degestão de fluxo de caixaGlauco Vinicius Argentino de Oliveira1Walter Mourão2 RESUMOMuitas organizações possuem dificuldades em realizar o controle efetivo de suainformação, uma vez que esta se encontra fragmentada nos diversos sistemas deinformação existentes e sem integração. Esse cenário acaba acarretando o atrasodos processos de tomada de decisão, principalmente por parte da alta gerência.Neste cenário a arquitetura orientada a serviços é uma abordagem dedesenvolvimento de sistemas de informação corporativos que busca manter o foconos processos de negócio, implementando-os como serviços reutilizáveis einteroperáveis. Esse trabalho tem por objetivo analisar a experiência daimplementação de alguns conceitos da arquitetura orientada a serviços em sistemade gestão de fluxo de caixa através da realização de um estudo de caso. Nodecorrer desse artigo serão definidos os principais conceitos relacionados á esseestilo arquitetural, compreendidas as dificuldades de integração com sistemaslegados e levantados aspectos importantes a serem observados durante a adoçãodesse paradigma.Palavras-chave: integração de sistemas, arquitetura de software, arquiteturaorientada a serviços.1 Analista desenvolvedor da SQUADRA Tecnologia em Software LTDA e aluno do curso superior deTecnologia 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 emSistemas para Internet do Centro Universitário de Belo Horizonte.Email: walter.mourao@gmail.com.
  2. 2. 21. INTRODUÇÃOEm geral, as empresas investem muito dinheiro em software e para que obtenhamum retorno sobre investimento esse software deve ser utilizado por vários anos. Noentanto com o passar do tempo os usuários exigem cada vez mais dos sistemas deinformação, inclusive dos sistemas legados: interfaces gráficas, tempo de respostapequeno, 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 pelofato de que muitos processos de negócios foram encapsulados em lógicas deaplicação no decorrer dos anos (BENNETT, 1995). Esses sistemas acabaram setransformando 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últiplasarquiteturas. 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çãoentre os ativos de Tecnologia da Informação (TI) é um desafio que as organizaçõesenfrentam quando tentam se manter competitivas e crescendo (MICROSOFT, 2006).
  3. 3. 3Figura 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 sistemasde informação heterogêneos, a arquitetura orientada a serviços (SOA3) ganhadestaque como uma abordagem capaz de promover o melhor alinhamento dodepartamento 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 nadistribuição do processamento através da criação e publicação de serviçosreutilizáveis, flexíveis e interoperáveis. Esses serviços são funcionalidadesespecíficas presentes nas aplicações corporativas e que dizem respeito ao negócioda empresa, e que podem ser disponibilizados para todas as demais aplicações de3 SOA é a sigla para Service Oriented Architecture ou Arquitetura Orientada a Serviços.
  4. 4. 4modo 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, seorganizam de tal forma que passam a ser criados a partir dos componentes queexecutam funções discretas de negócio. Estes componentes, denominados“serviços”, podem ser distribuídos e ajustados em um novo processo de negócioassim que necessário. O objetivo é permitir às empresas realizar negócios e obtervantagens 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 ereutilização de serviços (SOUZA JÚNIOR et al, 2007).Segundo (IBM, 2005), a arquitetura orientada a serviços oferece aos negócios osseguintes 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 osseguintes 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çosainda é baixa, bem como a quantidade de material científico publicado no idiomaportuguês a respeito do assunto.O principal objetivo desse trabalho é analisar uma experiência da implementaçãodos conceitos da arquitetura orientada a serviços em sistema de informação domundo real. Para tanto, os objetivos secundários são:
  5. 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 adecisõ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çãoque utiliza conceitos da arquitetura orientada a serviços. Nesse estudo de casoserão identificadas as principais dificuldades observadas durante a implementaçãobem como um conjunto de boas práticas identificadas.O estudo de caso foi selecionado como metodologia para o desenvolvimento dessetrabalho pelo fato de ser um tipo de pesquisa qualitativa que visa compreender eevidenciar o “como” e “porque” de um determinado cenário. É um tipo deinvestigação a respeito de uma situação específica que procura descobrir suaessência e características e que possui um forte cunho descritivo, sem ainterferência do pesquisador sobre a situação.O trabalho de pesquisa consistiu em uma série de reuniões presenciais com osprofissionais envolvidos no processo de desenvolvimento. Houve uma intensapesquisa 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 deincorporar alguns dos princípios da arquitetura orientada a serviços e ser umprimeiro passo para a adoção desse estilo arquitetural por toda a empresa.
  6. 6. 62. MARCO TEÓRICOA arquitetura orientada a serviços consiste em três elementos principais que serãoapresentados em maiores detalhes no decorrer do artigo:  Serviços;  Infra-estrutura;  Políticas e processos.2.1 ARQUITETURA DE SOFTWAREPara compreender o conceito de arquitetura orientada a serviços é necessáriocompreender o que é a arquitetura de software e qual a sua importância em umprojeto de software.Em sua obra, Bass, Clements e Kazman definem a arquitetura de software comosendo a estrutura de um sistema computacional, que abrange os componentes desoftware que compõem esse sistema, suas propriedades visíveis externamente e orelacionamento entre eles.Pressman ainda enfatiza que a arquitetura não é o software operacional, mas simuma 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 principaisrazões para justificar a arquitetura de software:
  7. 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ÇOSA arquitetura orientada a serviços é um paradigma que tem como principal objetivo aexposição e reuso intenso de serviços, componentes de software que executamtarefas específicas relacionadas ao negócio, de maneira pouco acoplada einteroperável, para que em médio prazo a tarefa de desenvolver uma aplicação sejaprimordialmente 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 comcaracterí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 bemcom 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. 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 grandeparte das aplicações e frameworks orientados a serviços. As característicasconsideradas 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. 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ÓCIOComo dito anteriormente, a arquitetura orientada a serviços é focada nos processosde negócio. Um processo do negócio pode ser automatizado por meio de sistemasde 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 maispassos e esses passos podem ser executados em sistemas diferentes.É possível desmembrar um processo de negócio em passos menores e maisconcretos. A Figura 2 fornece uma representação possível desse conceito, noentanto, deve-se ter em mente que o número exato de camadas e terminologiapodem variar de acordo com o ambiente.
  10. 10. 10Figura 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 funcionalidadede negócio. Sendo assim, um serviço pode ser definido como uma tarefa repetitiva eespecífica dentro de um processo de negócio (IBM, 2005), uma peça independentede funcionalidade que pode ser descoberta na rede, e que descreve o que ela podefazer 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ésde redes corporativas (IBM, 2005).Pelo fato desses serviços serem implementados tendo em vista o negócio, aspessoas 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 deabstração os detalhes específicos da plataforma não importam.
  11. 11. 11Muitas definições da arquitetura orientada a serviço que foram encontradas nodecorrer do desenvolvimento desse artigo, afirmam que a implementação dosserviços deve ser realizada utilizando-se os XML Web Services. Muitos atéconfundem a arquitetura orientada a serviços com essa tecnologia. Os XML WebServices são apenas uma maneira para implementar a arquitetura orientada aserviços, contudo, o conceito dessa arquitetura não está vinculado a nenhumatecnologia específica.2.4. ENTERPRISE SERVICE BUSO ESB (Enterprise Service Bus ou Barramento de Serviços Corporativos) é parte dainfra-estrutura da arquitetura orientada a serviços e provê um modo dosconsumidores 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 oscompostos (serviços compostos por outros serviços). Esse estágio introduz umacamada adicional para os serviços,denominada camada de orquestração.
  12. 12. 12Figura 3 – Representação da interação entre serviços, orquestração de serviços, ESB e consumidorde 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. 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 MANAGEMENTO Gerenciamento de Processos de Negócios (BPM) freqüentemente é relacionado àarquitetura orientada a serviços. O BPM é uma disciplina de gerenciamento quecombina a gestão de negócio com a TI, buscando a melhoria dos processos denegó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 asorganizações alcancem seus objetivos (MICROSOFT, 2006).O BPM promove a agilidade organizacional e suporta os esforços dos funcionáriospara o direcionamento de mudanças no processo e rápida inovação. Para isso, oBPM suporta o alinhamento do TI e das atividades de negócios dentro da empresa efora dela, com parceiros comerciais e fornecedores (MICROSOFT, 2006).Um processo de negócio pode ser caracterizado como um conjunto de tarefasque envolvem pessoas e recursos para que possa se atingir um objetivo bemdefinido. Como resultado deste, é gerado um produto ou serviço que vai aoencontro dos desejos dos clientes.Os processos de negócios podem ser estruturados ou não, dependendo do grau demobilidade dos passos subjacentes, ou seja: automatizados ou mutáveis,geralmente executados apenas por pessoas ou por pessoas interagindo comsistemas. As pessoas são uma parte essencial de quase todos os processos denegócios – elas direcionam as soluções e as percepções que fazem uma empresaavançar e, portanto, o objetivo deve ser capacitá-las para criar inovações e seremmais produtivas (e não uma “reengenharia” de pessoas que as exclua do processo).
  14. 14. 143. ESTUDO DE CASONeste estudo de caso será apresentado um projeto de software em desenvolvimentopara uma grande empresa de engenharia do Brasil. Essa empresa atua a mais de50 anos no mercado de construção pesada no Brasil e no Exterior, desenvolvendoprojetos 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 deirrigação e manutenção industrial onshore4 ou offshore5.3.1. PROPÓSITOEsse projeto de software consiste no desenvolvimento de um sistema de gestão dofluxo de caixa e tem por objetivo melhorar e unificar o processo de fluxo de caixa.3.2. O PROCESSO DE FLUXO DE CAIXAO fluxo de caixa pode ser considerado uma demonstração visual das receitas edespesas distribuídas em uma linha do tempo e consiste na previsão de entradas esaídas de recursos financeiros em um determinado período. O principal objetivodessa previsão financeira é fornecer informações para a tomada de decisões, taiscomo:  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. 15Para montar essa projeção do fluxo de caixa, é necessário levar em consideração osseguintes 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 eavaliação de uma empresa, proporcionando ao administrador uma visão futura dosrecursos financeiros da empresa, integrando o caixa, as contas correntes embancos, 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 ATUALAtualmente, essa empresa convive com os seguintes problemas referentes ao fluxode 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. 16Todos esses problemas contribuem para o aumento da dificuldade em antever comassertividade a sobra e a falta de caixa em médio prazo, um grande volume detrabalho e retrabalho e a dificuldade em captar e aplicar recursos no mercado demaneira mais adequada.ERP (Enterprise Resource Planning) são sistemas de informação desenvolvidospara integrar dados, processos e departamentos de uma organização possibilitandoa 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) esob a perspectiva sistêmica (sistema de processamento de transações, sistemas deinformaçõ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 linguagemchamada 4GL e utiliza banco de dados IBM INFORMIX. Ele é composto por umasé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 planilhaseletrônicas. Para a realização das previsões financeiras, cada área funcional enviauma planilha com seus dados e a unificação desses dados é realizadamanualmente.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. 17Buscando modelar e melhorar seus processos de negócio, foi contratada umaconsultoria no ano de 2006. Essa consultoria detectou uma série de pontos amelhorar, e o projeto de desenvolvimento desse software é um dos passospropostos para a melhoria do processo de fluxo de caixa.Durante a fase de concepção desse projeto foram identificadas algumascaracterísticas que influenciaram na decisão de utilizar conceitos da arquiteturaorientada 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ógicocorporativo homogêneo. Para tanto, foi decidido que todos os novos sistemas deinformação deveriam ser desenvolvidos utilizando-se a plataforma Microsoft .NET.Seguindo essa tendência, a empresa optou pelo desenvolvimento desse novosistema de informação utilizando o .NET Framework 2.0.3.4. SOLUÇÃO PROPOSTATendo em vista os problemas levantados junto ao cliente e apresentadosanteriormente, foi pensada uma arquitetura que promovesse a criação de um novosistema de informação para atuar como uma camada acima do legado. Esse novosistema 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 dedados. Essa base de dados posteriormente será utilizada para a criação de umsistema 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. 18o fluxo de caixa. Dessa maneira a empresa poderá agir de uma maneira maisproativa diante dos eventos financeiros.Com o intuito de possibilitar uma maior flexibilidade nas mudanças e otimizar osprocessos de negócio, foi incorporada uma abordagem orientada a processos. Ointuito do BPM é orquestrar o fluxo de chamadas dos serviços e criar serviçoscompostos.Para implementar o BPM foi escolhido o jBPM. jBPM é uma ferramenta de gerênciade processos para o ambiente Java reconhecida pelo mercado. O principal motivopara sua escolha foi o fato de que o driver de acesso ao banco de dados utilizadopelo cliente (IBM INFORMIX) possuir uma série de problemas de compatibilidadecom o Microsoft .NET Framework, principalmente no que diz respeito ao suporte átwo phase commit (2PC7). Esse problema não ocorre no ambiente Java e porconsequê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 apenasprocessos executáveis (sem a interação de seres humanos). Para a modelagem dosprocessos de negócio foi utilizada então a linguagem XPDL (XML Process DefinitioLanguage) que é uma linguagem que permite o mapeamento de processos denegó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 asdemais aplicações como XML Web Services. A utilização dos XML Web Servicesdeve-se ao fato dessa ser uma tecnologia amplamente suportada atualmente e quepermite a interoperabilidade dos diversos sistemas de informação, sendoindependente da linguagem de programação utilizada e plataforma. Os detalhesreferentes à XML Web Services não são descritos nesse trabalho, uma vez que7 É 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 segundafase o commit das atualizações normalmente sejam bem sucedido. De acordo com o princípio deacoplamento fraco, compensação é o termo usando em SOA, no lugar de 2PC.
  19. 19. 19constituem um assunto bastante extenso e não constituem parte essencial daarquitetura orientada a serviços.Cabe uma importante observação quanto aos XML Web Services: a simplesutilização destes em um projeto de software, não qualifica o software como orientadoa serviços. Grande parte ou todos os conceitos tratados anteriormente nesse artigodevem fazer parte da cultura organizacional para que uma solução de softwarepossa ser denominada realmente como orientada a serviços. A partir disso, tem-seque XML Web Services são meramente uma forma de se implementar a arquiteturaorientada a serviços, mas não parte essencial dela.A decisão de expor esses serviços não partiu da equipe de desenvolvimento, massim da empresa. Todos os serviços expostos foram elencados e constituem seusprincipais processos de negócio.O papel dos serviços neste cenário é disponibilizar funcionalidades as quais poderãoser facilmente acopladas nos processos. Estes serviços têm a característica deserem focados em objetivo, por este motivo, os serviços são rotinas concisas e comum escopo bem definido. Isto é feito com o objetivo de não possuírem serviços quesobreponha funcionalidades que possam estar em outros serviços.Visando prover conectividade entre a aplicação e os serviços criados, foiimplementado um barramento corporativo de serviços (ESB) pala equipe dedesenvolvimento. Esse barramento não possui todas as funcionalidades previstasem um barramento adquirido comercialmente, entretanto, atende ás necessidade doprojeto em um primeiro momento. Dentre as funcionalidades ofertadas por essecomponente 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. 20possibilita que outros sistemas ou subsistemas possam utilizar dos serviçosdisponibilizados. Existiu a demanda de um barramento neste cenário devido ànecessidade de integração com sistemas legados, bem como o reaproveitamento deserviços por outros sistemas.4. CONCLUSÃOA 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 produtividadee a lucratividade no desenvolvimento e manutenção de software. Sua capacidade delidar bem com ambientes heterogêneos permite que novos softwares sejam criados,independente de linguagem de programação ou plataforma, tendo como focoprincipal o negócio.A criação e exposição de serviços oferecem uma série de benefícios, tanto no quetange à rapidez do desenvolvimento, como na redução de custos e prazos nadistribuição de sistemas. Ela possibilita integração de sistemas de plataformasdiferentes (.NET, J2EE, CORBA), tornando o ambiente corporativo interoperável.Este estilo arquitetural não introduz nenhum conceito novo. É um paradigma quereúne os principais conceitos e práticas de integração de sistemas já existentes.Outro aspecto importante é o fato desse paradigma aceitar a heterogeneidade doambiente corporativo, ao contrario de outras abordagens precursoras.Assim como todo e qualquer paradigma ou tecnologia, a arquitetura orientada aserviços não deve ser encarada como uma “bala de prata”. Apesar de todas asvantagens ofertadas pela utilização desse paradigma, deve-se ponderar a respeitode sua utilização em cada cenário. Esse e um paradigma cujo custo deimplementação pode ser relativamente caro caso o ambiente corporativo sejahomogêneo. Para ambientes homogêneos existem soluções mais simples e demenor custo.
  21. 21. 21Durante o desenvolvimento desse trabalho foram definidos os principais conceitosrelacionados á arquitetura orientada a serviços, bem como foram apresentadosalgumas das dificuldades encontradas na integração de sistemas de informação nocontexto corporativo.Com base nesse estudo de caso e na experiência da equipe que compõe esseprojeto, que já participou de outros projetos envolvendo EAI e SOA, foramidentificados alguns aspectos importantes a serem observados durante a adoção deSOA 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. 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 (fasede construção, segundo o RUP8). Entretanto isso não é um empecilho para que omesmo seja utilizado como referencial desse trabalho, uma vez que a arquiteturaproposta está bem-definida e mudanças no escopo serão pouco significativas. Para8 O Rational Unified Process (RUP) é um framework de processos da IBM Rational guiado por casosde uso, centrado na arquitetura, e que propõe o desenvolvimento de software de modo iterativo eincremental.
  23. 23. 23trabalhos futuros, espera-se relatar o término desse processo de desenvolvimento eos passos conseguintes da adoção da arquitetura orientada a serviços por essaempresa.
  24. 24. 24Study about the application of the service oriented architecture in a cash flowmanagement system ABSTRACTMany 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 managementteam. In this scenario, the Service Oriented Architecture (SOA) is a corporateinformation 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-orientedarchiteture concepts in a cash-flow management system, through a case study. I thecourse of this article, the main concepts of that architectural style will be related,since the dificulties of integrating with legacy systems are known, and importantaspects to be watched during the adoption of that paradigm.Keywords: Systems Integration, Software Architecture, Service OrientedArchitecture
  25. 25. 25 REFERÊNCIASBASS, CLEMENTS, KAZMAN. Software Architecture in Practice, 2nd edition,Addison Wesley, 2003, p.44.BENNETT, K.H. Legacy Systems: Coping With Success, IEEE Software, January1995, Vol 12, No. 1, pp 19-23IBM CORPORATION, IBM’s SOA Foundation: An Architectural Introduction andOverview, November 2005.IBM CORPORATION, Introduction to the Value and Governance Model ofService-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 aServiços, 2004. Trabalho acadêmico – (Tese de Mestrado) – Pontifica UniversidadeCatólica do Rio de Janeiro, Rio de Janeiro, 2004.MICROSOFT CORPORATION, Ativando uma “Arquitetura Orientada a ServiçosRealista” na Plataforma Microsoft, Dezembro 2006.PRESSMAN, Roger. Software Engineering: A Practitioners Approach, 5thedition, McGraw-Hill, 2000, p.366-368.SANTOS, Cássio Rogério Celestino, Gerência de Risco na Modernização deSistemas Legados. 2004. Trabalho acadêmico – (Monografia) – Escola Politécnicada 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çãoorientada a serviços dos sistemas de informação do CEFET-AL, 2007. Trabalhoacadêmico – (Artigo Científico) – CEFET-AL, Maceió, Alagoas.`
  26. 26. 26Meus sinceros agradecimentos á minha família pelo apoio,meus amigos pelo companheirismo e estímulo e meuorientador por acreditar em meu potencial e por me orientar,permitindo-me realizar esse trabalho.Obrigado por me ensinarem com prazer e dedicação parte doque sei e, o que é mais importante, me ensinarem a aprendersozinho.

×