2.

EVOLUO DAS TECNOLOGIAS DE INTEGRAO Nas ltimas dcadas, diferentes abordagens foram adotadas pelas organizaes com o objetivo de integrar sistemas. Quer seja para compartilhar dados armazenados em diferentes sistemas quer para aproveitar funcionalidades existentes nesses sistemas. No incio, um problema recorrente era o fato dos sistemas no serem projetados para se integrar uns aos outros. Alm disso, as primeiras tentativas de integrao no seguiam padres ou normas tcnicas, dada a sua inexistncia. A crescente necessidade do uso de tcnicas e metodologias nesta rea e, ainda, a prpria evoluo tecnolgica, impulsionaram a criao das primeiras especificaes, que tm sido aperfeioadas. Mesmo aps o aparecimento e disseminao de tecnologias modernas, flexveis e escalveis, o mercado ainda tem tratado a questo da integrao de sistemas de informao com certo desleixo. Fato que pode ser observado com uma anlise das solues tpicas adotadas costumeiramente pelas empresas, a saber (MARTINS, 2005): 1) transferncia de arquivos, na qual cada aplicao produz arquivos de dados compartilhados para alimentar outras aplicaes e vice-versa; 2) compartilhamento de banco de dados, na qual as aplicaes armazenam os dados que elas querem compartilhar em uma base de dados comum; 3)

replicaes e redundncias, na qual uma nova base com os dados replicados gerada, com livre acesso para todas as aplicaes; 4) integraes ponto a ponto, que utilizam um backbone de conexes simples ponto a ponto entre as aplicaes que necessitam interagir; 5) troca de mensagens, na qual cada aplicao se conecta a um sistema de troca de mensagens, atravs do qual possvel a troca de dados; 6) chamada de procedimento remoto, no qual cada aplicao disponibiliza alguns dos seus procedimentos para que eles possam ser chamados remotamente. O principal objetivo da integrao a obteno de sistemas que facilitem o acesso a dados e procedimentos sem qualquer barreira funcional. Em conseqncia, as aplicaes resultantes podem corresponder a combinaes de componentes de diferentes reas tecnolgicas. Nesse contexto, Martins (2005) identifica as quatro perspectivas tecnolgicas mais comuns e mais abrangentes das modalidades de integrao: 1) Integrao da Informao, na qual o foco a gesto e a disponibilizao da informao; 2) Integrao da Aplicao, na qual as aplicaes consistem no principal alvo e a sua integrao o objetivo principal; 3) Integrao de Processos, na qual os processos organizacionais consistem no foco das atenes sendo a integrao realizada atravs de uma lgica processual; 4) Integrao InterOrganizacional, na qual o foco a informao e a sua forma de intercmbio entre organizaes, extrapolando as fronteiras corporativas. A evoluo dos mercados e das tecnologias fez surgir novas formas de abordagem da integrao de sistemas. Atualmente, existem correntes tecnolgicas que defendem diferentes perspectivas e abordagens para a integrao de sistemas. Cada uma delas tem solues focadas para a sua rea, chegando por vezes a compartilhar funcionalidades das restantes. Esta realidade dificulta a escolha das solues mais adequadas s necessidades organizacionais e complica o entendimento das tecnologias existentes nesta rea (MARTINS, 2005). A evoluo dos padres acontece medida que os prximos estgios necessitam buscar, cada vez mais, a flexibilidade nos mecanismos de integrao. A Figura 1 ilustra a evoluo das tecnologias de integrao em um determinado perodo de tempo, desde o uso dos mainframes e da criao da Internet, at o surgimento da web e sua larga difuso. Percebe-se que nos ltimos anos h uma convergncia e sobreposio de tecnologias, o que torna a sua classificao mais difcil.

Figura 1. Evoluo das tecnologias de integrao de sistemas. Fonte: Martins (2005).

Segundo Martins (2005), por fora da evoluo do mercado tecnolgico, certas normas sobrepem-se em algumas reas, ou so incompatveis, o que aumenta a dificuldade no entendimento e na escolha da soluo mais adequada. Normalmente, a integrao de sistemas de informao est associada aos termos Enterprise Application Integration (EAI) (EAI, 2007) ou Business Process Management (BPM) (HOLLINGSWORTH, 2004) que tm pontos em comum e que por vezes so complementares. O recente surgimento dos Web Services

(WS) (WEB SERVICES, 2007) e da Service Oriented Architecture (SOA) (ERL, 2007) criou novas alternativas s abordagens mais tradicionais. Em (EAI, 2007) e (EAI/SOI, 2007) so definidos padres e melhores prticas para arquitetar solues escalveis e de fcil integrao. Os padres da EAI so bastante abstratos para serem aplicados com a maioria das tecnologias de integrao, mas especficos o suficiente para prover um guia ou catlogo para projetistas e arquitetos. Padres tambm proporcionam um vocabulrio para os desenvolvedores descreverem eficientemente suas solues. Os padres no so inventados, eles so catalogados atravs do uso repetitivo na prtica de solues bem sucedidas nos projetos. Em (EAI, 2007) tem-se uma descrio detalhada de cada um deles. Entretanto, as solues tradicionais de EAI provem uma mquina de integrao centralizada e monoltica, que usa tecnologias proprietrias para integrar os sistemas, e adaptadores especializados para conectar fontes de dados e sistemas legados. Dextra Sistemas (2007) aponta algumas desvantagens dessa abordagem: depende da plataforma, que requer uma nova verso tanto da mquina de integrao quanto dos adaptadores para cada plataforma a ser suportada ou integrada; introduz uma linguagem proprietria no ncleo da integrao; resulta num nico ponto de falha; prov um mtodo de integrao que se baseia na replicao dos dados dos diversos sistemas ao invs de consolidar os dados das vrias fontes. Martins (2005) destaca que, alm das diferentes perspectivas e tcnicas existentes, a evoluo da TI na rea de integrao tem revelado que os processos organizacionais se constituem, cada vez mais, o centro das atenes. Este aspecto se deve importncia desses processos em uma organizao pela sua natureza estruturante (ALVES, 1995). As solues de BPM mais recentes incluem praticamente todas as tecnologias e conceitos de integrao de sistemas que surgiram ao longo dos tempos. A arquitetura SOA desponta como o mais novo paradigma de desenvolvimento de sistemas. SOA representa uma nova forma de pensar quanto ao projeto da arquitetura de um sistema e sua posterior integrao a outros sistemas. E define o modo pelo qual as funes de negcios separadas, implementadas por sistemas autnomos, interoperam para executar processos de negcios. Por se tratar da abordagem adotada para este trabalho, a prxima seo apresenta os aspectos relevantes desta arquitetura. 3. ARQUITETURA ORIENTADA A SERVIOS - SOA A Arquitetura Orientada a Servios, do ingls Service Oriented Architecture, ou simplesmente SOA, refere-se a um estilo de planejamento da estratgia de tecnologia da informao diretamente alinhado aos objetivos dos negcios de uma organizao (ERL, 2007). Este alinhamento permite a traduo das funcionalidades das aplicaes em servios padronizados e interrelacionados. A orientao a servios se tornou mais vivel devido ampla adoo dos web services. Essa tecnologia possibilita a utilizao das SOAs de forma a permitir que as aplicaes se comuniquem entre si de modo independente da plataforma e linguagem de programao. O seu foco est na estruturao integrada das atividades de negcio e no no desenvolvimento e implementao de solues isoladas. SOAs permitem a operao integrada de tecnologias, o compartilhamento e a reutilizao de servios em ambientes distribudos. O resultado desse planejamento, que alia tecnologia e negcio, um conjunto de servios interligados que perpassam a transferncia de dados e a coordenao de atividades. Os aplicativos baseados em SOA so independentes da plataforma e da linguagem e so compatveis com os padres mais aceitos pelas indstrias (NEWCOMER; LOMOW, 2004).

ERL (2005) explica que na medida em que esto centrados em torno de servios, os modelos organizacionais baseados em SOA associam as funcionalidades tecnolgicas diretamente aos objetivos de negcios, num encadeamento de processos integrados. Primeiramente os processos de negcio so examinados a partir de uma parceria entre as reas de TI e gestores; alm disso, so identificados os sistemas existentes e as solues tecnolgicas necessrias para atend-los. Para cada processo de negcio so associadas as funcionalidades tecnolgicas correspondentes, como informaes de entrada e sada, e a interface do servio a que esto relacionados. Estas funcionalidades so avaliadas, catalogadas e categorizadas, para o estabelecimento de padres de sada e eliminao de redundncias. Em seguida, a padronizao das funcionalidades explicitada sob a forma de servios, que atuam de maneira integrada para atender aos processos de negcios. Cada servio desenvolvido, testado e disponibilizado para uso nos aplicativos associados sua funcionalidade. A regulamentao atravs dos servios prov as mtricas para a avaliao do seu desempenho, que varia em funo dos indicativos de negcios e da sua aderncia s expectativas. Por fim, a avaliao dos servios expe as oportunidades de aperfeioamento do modelo, completando um ciclo de alinhamento e interlocuo que se auto-alimenta. SOA trouxe tona a necessidade de fortalecer o enfoque no cliente e tornar a gesto de servios uma atividade produtiva, que agrega valor empresa. (RABELO, 2006) enfatiza que essa atividade fortemente dependente das pessoas. A caminhada rumo a SOA rdua, pois exige um forte investimento na evoluo organizacional, no estabelecimento de um gerenciamento eficaz de pessoas, orientado a conhecer as suas potencialidades, objetivos e desejos em detrimento dos objetivos da organizao, direcionando a gerncia de servios de acordo com o desempenho individual exigido por cada stakeholder do projeto. O princpio que rege uma SOA de que uma aplicao grande e complexa deve ser evitada e substituda por um conjunto de aplicaes pequenas e simples. Ou seja, uma aplicao passa a ser fisicamente composta por vrios e pequenos mdulos especializados, distribudos, acessados remotamente, interoperveis e reutilizveis de software que so unidos graas a padronizaes adotadas, podendo ainda ser rapidamente recomposta para o processo desejado (ERL, 2007). No mundo SOA esses pequenos mdulos de software so chamados de servios. Um servio um mdulo de software, que pode ter uma granularidade varivel, pode ser implementado em qualquer linguagem de programao e tem uma interface padro que permite que ele invoque um servio e tambm possa ser invocado por outro servio. Portanto, um mesmo servio pode ser tanto cliente como servidor, dependendo da composio feita para os vrios processos de negcio da empresa. A seleo de servios e a seqncia de suas invocaes que determinam o comportamento, ou seja, a funcionalidade global da aplicao associada a um dado processo de negcio. A Arquitetura Orientada a Servios pode ser bem representada a partir de um processo conhecido como "find-bind-execute paradigm", que pode ser traduzido como "procuraconsolida-executa". Esse conceito anlogo ao Ciclo de Deming" aplicado aos servios, que envolve o planejamento, a execuo, o monitoramento e a tomada de ao pr-ativa para a melhoria da qualidade (CAMPOS, 2002). O supracitado processo preconiza que os provedores de servios registram informaes em um registro central, com suas caractersticas, indicadores, e aspectos relevantes s tomadas de decises. O registro utilizado pelo cliente/consumidor para determinar as caractersticas dos servios necessrios, e se o mesmo estiver disponvel no registro central, como por exemplo, por um catlogo de servios, o cliente poder utiliz-lo, sendo este oficializado atravs de um contrato que efetua o endereamento deste servio

(IBM, 2005). SOA se baseia na capacidade de identificar servios e suas caractersticas. Este processo de descoberta depende, portanto, de um diretrio que descreve quais os servios disponveis dentro de um domnio. A relao entre os servios do provedor e do consumidor deve ser idealmente dinmica. Ela estabelecida em tempo de execuo atravs de um mecanismo de binding. Os processos de sequenciar servios e prover uma lgica adicional para processar dados so conhecidos como orquestrao. A Figura 2 apresenta as camadas complementares da arquitetura SOA: front-end, servios, repositrio, ESB (Enterprise Service Bus) e SOA propriamente dito. Na camada superior encontram-se os front-ends das aplicaes que interagem com os servios. Os frontends so as interfaces dos servios para os usurios finais, reponsveis pela iniciao e o controle da execuo dos servios. O contrato, por sua vez, consiste em processos e em representaes de dados pblicos. O processo pblico o ponto de entrada para o servio, ao passo que a representao de dados pblica simboliza as mensagens usadas pelo processo. O contrato tambm deve ser projetado para permitir a evoluo do servio sem romper contratos com antigos consumidores. A camada de repositrio responsvel por armazenar todos os contratos dos servios disponveis e consiste no ponto de partida para utilizao destes. Alm dos contratos, o repositrio pode armazenar informaes adicionais e mais especficas acerca dos servios, como localizao fsica, restries de uso, segurana, dentre outras. As interfaces, por sua vez, referem-se aos contratos estabelecidos entre o repositrio e o ESB. Devem ser relativamente simples, projetadas para aceitar uma mensagem de entrada bem definida e para responder com uma mensagem de sada igualmente bem definida.

Figura 2. Camadas complementares da arquitetura SOA.

A camada de mais baixo nvel utiliza o conceito de Enterprise Service Bus (ESB), que se baseia em uma arquitetura que herda caractersticas dos Message Brokers (Martins, 2005), funcionando como uma plataforma empresarial para implementar interfaces de comunicao atravs de troca de mensagens. O ESB atua como um repositrio virtual, mediando a comunicao entre os consumidores e os servios e criando um ambiente propcio de administrao. Se bem modelados, os servios disponibilizados no barramento podem agregar valor e facilitar o reuso ao encapsular as particularidades e complexidades do ambiente de integrao, abstraindo a complexidade tcnica que existe nas camadas inferiores. O ESB representa uma espinha dorsal de servios, mensagens, comunicaes, transformaes e segurana, sobre a qual se pode acoplar aplicaes ou simplesmente interagir com elas. Essa abordagem beneficia-se da grande maioria das normas e solues tcnicas comentadas anteriormente, em particular os conceitos de troca de mensagens, Web Services e protocolos de comunicao. Os ESB seguem os princpios de SOA, permitindo a integrao com diferentes tipos de servios, cuja camada de comunicao baseada em um canal centralizado onde trafegam os servios, gerando a troca de mensagens e garantindo o

seu encaminhamento, aplicao de regras e condies, mapeamento e transformao de dados. Essas mensagens so normalmente estruturadas em XML (XML, 2007) o que permite a portabilidade das mensagens. SOA pode ser utilizada em inmeros e diferentes nveis. IBM (2005) define quatro nveis de adoo de SOA de acordo com o grau de maturidade e transformao das reas de tecnologia e de negcios. O primeiro nvel preconiza a implementao individual dos Web Services, criando servios a partir de tarefas que fazem parte de novas e antigas aplicaes. O segundo nvel est relacionado integrao de servios atravs de diversas aplicaes dentro e fora da empresa para um objetivo de negcios. O terceiro est relacionado capacidade de integrao atravs de funes de negcios por toda a empresa atingindo uma escala corporativa. E, por ltimo, no quarto nvel a empresa procura atingir o direcionamento estratgico em busca de uma transformao abrangente de modelos de negcios existentes ou de implementao de novos.