Recomendados
Mais conteúdo relacionado
Semelhante a Histórico das Aplicações Corporativas e Evolução Tecnológica
Semelhante a Histórico das Aplicações Corporativas e Evolução Tecnológica (20)
Histórico das Aplicações Corporativas e Evolução Tecnológica
- 1. Um Breve Histórico das Aplicações Corporativas David Barreto Ferreira, Leonardo Pacheco1 1 Prill Tecnologia http://www.prill.com.br {david.ferreira,leonardo.pacheco}@prill.com.br Abstract. This paper describes the business applications evolution over the past years, according to information technology changes. We’ll present the advantages and disadvantages of using each kind of technology as well as the path that led corporations to adopt the SOA architecture and enterprise integration patterns. Resumo. Este artigo relata a evolução das aplicações corporativas ao longo dos anos, de acordo com as mudanças sofridas na tecnologia da informação e seus paradigmas. Serão apresentadas as vantagens e desvantagens obtidas com o uso de cada tecnologia, e o caminho que levou as corporações a adotar arquiteturas SOA e os padrões de integração de sistemas. 1. Introdução Desde o século XIX havia propostas de máquinas programáveis para automatizar tarefas, mas foi a demonstração por Turing de que era possível implementar uma máquina genérica para executar tarefas arbitrariamente complexas que iniciou a corrida pela criação dos computadores. Ao longo dos anos, a necessidade de informações para suportar o controle e tomada de decisão nos negócios levou a expansão da aplicação da tecnologia da informação nas empresas e a criação de inúmeras aplicações corporativas. A história dos sistemas computacionais nas empresas começa na era do mainframe (Seção 2), passando pelos microcomputadores (Seção 3), arquitetura cliente-servidor (Seção 4) e a web (Seção 5). O desenvolvimento de aplicações para web se popularizou, e a necessidade de separação de interesses entre os componentes deu origem a arquiteturas multicamadas (Seção 6). Por conta da necessidade de interoperabilidade entre as aplicações corporativas, foram desenvolvidos métodos para prover integração entre os sistemas (Seção 7), e mais tarde a definição de arquiteturas SOA (Service-Oriented Architecture) (Seção 8). Os processos de negócio das empresas logo passaram a ser desenhados através de ferramentas BPM (Seção 9), facilitando sua criação, manutenção e evolução. Por fim, nos dias atuais as aplicações corporativas têm migrado para ambientes de computação em nuvem (Cloud Computing) para reduzir custos com infraestrutura e serviços (Seção 10). 2. Mainframe Na década de 1950 surgiram os primeiros mainframes, computadores de grande porte utilizados por corporações para processar grandes volumes de informação. A alta da
- 2. utilização dos mainframes se estendeu até a década de 1970, onde o mercado era liderado por fabricantes como IBM, Burroughs, Honeywell, UNIVAC e outros. Figura 1. O mainframe e os terminais burros Inicialmente estas máquinas eram muito caras e absurdamente lentas para os padrões atuais, sendo usadas apenas para aplicações batch. Os usuários escreviam os programas e os armazenavam em cartões que eram submetidos para processamento quando havia disponibilidade de máquina. O processamento batch era incômodo aos usuários, mas permitir acesso direto a um usuário por vez era ineficiente, devido aos períodos prolongados em que a máquina ficava ociosa esperando a entrada do usuário. Para conciliar as duas necessidades, surgiu o acesso compartilhado, em que vários usuários se conectam a uma mesma máquina, de forma a melhor aproveitar seus recursos: a máquina está constantemente ocupada com algum processamento mesmo havendo usuários ociosos. Os usuários acessavam os recursos através de terminais sem poder de processamento, conectados ao mainframe. Esses terminais eram conhecidos como terminais burros (dumb terminals). As aplicações escritas para mainframes eram tipicamente monolíticas, com interface com o usuário, lógica do negócio e acesso aos dados fazendo parte de um único grande programa. Esse tipo de aplicação é difícil de manter e evoluir. Entretanto, o fato do acesso aos sistemas serem feitos por terminais sem poder de processamento implicava que as aplicações executassem exclusivamente no mainframe, fazendo a arquitetura monolítica razoável, além de trazer ganhos em integridade e acessibilidade dos dados, por conta da sua característica centralizada. 3. Microcomputador Na década de 1960, fatores como a substituição das válvulas por transistores e o uso de circuitos integrados, tornaram possível a construção de computadores que ocupassem menos espaço e custassem mais barato. Isso permitiu o aumento do acesso a computadores para empresas ao longo da década de 1970. Nesta década foram construídos os primeiros microcomputadores, também conhecidos como computadores pessoais (PC, personal computer), pois apenas podiam ser utilizados de maneira exclusiva. Inicialmente os minicomputadores eram vistos apenas como uma forma de amadores terem acesso a tecnologia de computadores, mas o lançamento do VisiCalc, a primeira planilha eletrônica, para os Apple II mostrou que estes equipamentos tinham potencial de uso também nas empresas e escritórios. Surgiram então diversas aplicações voltadas para simplificar o trabalho do usuário, como processadores de texto, planilhas eletrônicas e
- 3. sistemas gerenciadores de banco de dados, levando a um aumento crescente do uso dos PC’s. A popularização dos microcomputadores gerou uma dificuldade: pulverização dos dados. Nos mainframes e minicomputadores a informação ficava centralizada nos computadores e era acessada por usuários em terminais, mas agora os usuários podiam produzir informação em PC’s que não tinham conexão entre si. 4. Arquitetura Cliente-Servidor As redes locais (LAN, local area network) surgiram para facilitar o compartilhamento de informações entre os PC’s, e com elas surgiu a arquitetura cliente-servidor. Pulverizar a capacidade de processamento resolveu o problema dos usuários em termos de conforto ao utilizar os sistemas, afinal agora eles tinham algum processamento local e podiam gerar respostas (e erros) mais rapidamente, aumentando a interatividade e consequentemente a produtividade, mas gerava o problema de desperdício de recursos. Os usuários continuavam ociosos a maior parte do tempo, então memória, armazenamento e processamento alocado nas máquinas dos usuários estavam sendo desperdiçados. Dedicando máquinas mais poderosas para funções comuns demandadas pelos usuários permitia o ganho de escala na aquisição e alocação de recursos. Na arquitetura cliente/servidor, algumas máquinas centralizam a alocação de recursos (os servidores) e as máquinas dos usuários (os clientes), conectadas a elas por redes locais, consomem dados e delegam processamento para elas. A transição para esta arquitetura nas corporações fez com que os dados ficassem centralizados nos servidores, facilitando o seu gerenciamento, porém criava a necessidade de instalação de software nas estações de trabalho. Com o aumento no número de clientes, surgiram as dificuldades de distribuição de software e suporte aos usuários. Máquinas diferentes tinham história de uso diferentes, gerando dificuldade de predição de falhas, já que podia haver incompatibilidade entre conjuntos de aplicações instaladas juntas, interferência do usuário na configuração da máquina, entre outros fatores. Ainda, ao contrário do que ocorria no mainframe, em uma arquitetura cliente-servidor frequentemente são utilizados equipamentos de diferentes fabricantes. Isso faz com que o gerenciamento dos sistemas fique mais complexo, além de aumentar os custos com suporte. Além disso, em caso de atualização da aplicação, seria necessário atualizar todos os clientes, o que dependendo do tamanho da empresa pode ser muito oneroso. Figura 2. Arquitetura cliente/servidor
- 4. 5. A Web A Internet foi criada na década de 70 como um projeto militar de pesquisa de interligação de sites por uma rede redundante, mas ao longo da década de 80 ela se espalhou interligado inúmeras universidades. Na década de 90, surge o conceito da web em que páginas hipertexto escritas em HTML podem referenciar umas as outras criando uma teia de documentos que simplificaria o acesso a informação e ao conhecimento devido a facilidade de navegação e a apresentação visual. O HTML e o HTTP, tecnologias fundamentais da web, não foram originalmente planejados para suportar o desenvolvimento de aplicações, mas as versões iniciais tinham um suporte rudimentar para o envio de informações. Sendo capazes de receber dados, os servidores passaram a suportar a construção de conteúdo dinâmico em resposta aos dados recebidos. As ferramentas iniciais para gerar este conteúdo também eram bem precárias, mas serviram para promover o interesse na tecnologia e formando um ciclo que criou a possibilidade de usar a web como uma plataforma de aplicações. Com a adição do Javascript para permitir processamento e interatividade dentro do próprio browser sem depender de uma requisição ao servidor, os browsers se tornaram clientes razoáveis para aplicações baseadas em formulários e listagem de informação (CRUD). Mais tarde, a Microsoft inadvertidamente viabilizou o AJAX ao incluir a chamada XmlHttpRequest no seu navegador Internet Explorer, visando inicialmente suportar apenas a interface web do Exchange Server, mas no processo culminou na possibilidade de que qualquer página web recebesse informações do servidor assincronamente. Estas tecnologias passaram a permitir que um cliente web se comunicasse com o servidor utilizando os protocolos padronizados para obter recursos, da mesma forma como era feito nos primórdios da arquitetura cliente/servidor, porém o mesmo software cliente pode ser utilizado para diversos fins, eliminando a necessidade de instalação de aplicações adicionais no cliente. O cliente faz requisições ao servidor para obter páginas e recursos necessários à interface com o usuário, bem como os dados da aplicação e execução de processamentos em maior escala. O uso desta tecnologia resolve o problema da atualização dos clientes. Uma vez que os protocolos são padronizados e o cliente é genérico, as atualizações dos sistemas são aplicadas somente no servidor. O cliente (browser) somente precisa ser atualizado caso haja uma atualização nos protocolos padronizados ou outros recursos referentes à infraestrutura de rede. Figura 3. Aplicações Web Corporativas 6. Arquiteturas multicamadas Nas implementações de aplicações cliente-servidor a camada cliente era responsável pela interface de apresentação e a camada do servidor pelo armazenamento de dados, enquanto a
- 5. lógica de negócio ficava distribuída entre as duas, de acordo com as decisões de implementação. Por exemplo, para garantir que todas as aplicações que compartilhassem um modelo de dados usassem as mesmas regras de negócio, estas podiam ser implementadas como stored procedures no banco de dados do servidor. Desta forma também se reduzia o fluxo de dados trafegados pela rede, porém a aplicação se tornava dependente da tecnologia de bancos de dados utilizada (a linguagem de desenvolvimento para procedures não é padronizada, e mesmo os tipos de dados variam entre bancos de fornecedores distintos). De outra forma, se a lógica de negócio estivesse implementada no cliente, então esta precisaria ser replicada em cada programa que acessasse o banco de dados, o que criava uma dependência com a linguagem de programação em que as regras foram implementadas ou em caso de uma duplicação de lógica, abria mais espaço para bugs nas aplicações. A solução comum era uma divisão da lógica de negócio entre as duas camadas, segundo as preferências da equipe de desenvolvimento. Com a evolução da tecnologia, criou-se a arquitetura em 3 camadas (3-tier Architecture), que modularizava o sistema em 3 componentes: a apresentação, lógica de negócio e dados. Este desacoplamento permitiu, por exemplo, que as camadas fossem atualizadas ou substituídas independentemente, em resposta a mudanças nos requisitos da aplicação ou na tecnologia. Figura 4. Arquitetura 3-tier 7. Enterprise application integration: Motivação Na arquitetura cliente-servidor, houve uma melhoria no gerenciamento dos dados, pois estes voltaram a ser armazenados em um local centralizado: o servidor. Entretanto, as aplicações coorporativas como CRM (Customer Relationship Management), HCM (Human Capital Management) e Billing tipicamente não se comunicavam com outras aplicações para compartilhar seus dados e regras de negócio, criando silos de informação (termo também conhecido como ilhas de automação). Não havendo padronização na modelagem de dados, nenhum sistema tomava para si a responsabilidade de buscar informações em outros sistemas, e comumente até implementavam funcionalidade redundante como um valor agregado, caso a empresa não tivesse orçamento para adquirir um sistema dedicado para atender alguma função. Nem se precisa dizer que geralmente o “valor agregado” era uma versão inferior da funcionalidade, e que mesmo assim a estratégia de venda dava resultado e a empresa se encontrava com dois sistemas usando os mesmos dados e os processos espalhados entre os dois. Como iniciativa de integração, as empresas criam então exércitos de jobs que tentam manter a sincronia dos dados comuns entre os sistemas, seja por extrações e cargas em batch ou por detecção de mudanças nos dados. É desnecessário dizer que estes jobs ou pecam por retardar a execução dos processos, ou geram resultados atrasados, e com frequência a
- 6. sincronia de dados falha e gera a demanda por jobs para conciliar bancos de dados entre sistemas. Surgem então plataformas de integração aplicações (EAI) que empacotam soluções para cenários de integração comuns, conectores para as aplicações corporativas de uso comum e ferramentas para que as empresas desenvolvam seus próprios conectores. Dessa forma, podemos dizer que é criado um workflow, que permite a automatização de processos que outrora não seriam factíveis de se construir. Os mecanismos criados para atingir a finalidade de integração dos sistemas são chamados de Enterprise Application Integration (EAI). 8. SOA Uma forma de realizar a integração entre as aplicações corporativas é utilizando-se o conceito de SOA (Service-oriented Architecture) na implementação das aplicações. Na definição do Gartener Group SOA é “uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas”. Isso significa que as aplicações compartilham seus recursos por meio de serviços com interfaces (contratos) bem-definidas. A abordagem de uso de adaptadores do EAI retirava a responsabilidade da integração das aplicações e a transferia para a plataforma de EAI, criando aí um ponto de dependência para a integração de novas versões das aplicações e implementação de novas funcionalidades. O SOA, por sua vez, transfere a responsabilidade pela “exportação” da interface de integração para as aplicações, que passaram e ser encaradas como provedoras de serviços. É muito comum em um ambiente SOA que os serviços sejam disponibilizados por meio de Web Services através SOAP/WSDL ou REST/WADL, porém podem ser utilizadas outras formas de comunicação. Uma vantagem de se utilizar Web Services para a construção dos serviços é a utilização de componentes e protocolos padronizados e independentes de plataforma. Existem implementações de Web Services para uma grande variedade de linguagens e plataformas, o que facilita a interoperabilidade entre sistemas de plataformas distintas, escritas em linguagens de programação distintas. Uma das principais características dos sistemas SOA, é o baixo acoplamento (loose coupling) entre os serviços. Dessa forma a manutenção em um serviço específico é facilitada, além de ocasionar a diminuição dos riscos de causar erros em outros pontos do sistema. Um outro aspecto importante é a possibilidade de reuso dos serviços em diversas aplicações. Uma vez que o serviço está disponível no ambiente SOA, ele pode ser invocado em diversas aplicações dentro do ecossistema. Figura 5. Arquitetura Orientada a Serviços
- 7. Além disso, a utilização de SOA nos projetos de TI permite, pela sua forte característica de prover interoperabilidade entre as aplicações, facilmente o emprego de ferramentas que auxiliam a modelagem de processos de negócio. Essas ferramentas são conhecidas como ferramentas de BPM (Business Process Management). Através do BPM pode-se modelar um processo de negócio em alto nível, e fazê-lo interagir com as aplicações necessárias por meio de chamadas aos serviços disponíveis no ambiente SOA. Por isso, SOA pode ser considerado um modelo de planejamento diretamente alinhado aos objetivos de negócio de uma organização. 9. BPM O objetivo do BPM é mapear e documentar processos de negócio através de uma linguagem clara e padronizada. O produto deste mapeamento é uma descrição dos processos em um formato que pode ser implementado por uma ferramenta de workflow, e assim se formou um mercado para plataformas dedicadas a implementar BPM. Estas plataformas casam ferramentas de desenho de processo com motores de workflow que consomem os documentos gerados e fazem o processo funcionar. As ferramentas permitem criar formulários para solicitar entrada de dados pelo usuário, enviar e receber informações de outros sistemas da empresa, medir a performance de execução dos processos, identificar gargalos e emitir relatórios. BPM e SOA combinam bem porque SOA visa empacotar serviços genéricos e reutilizáveis, que podem ser consumidos pelas plataformas de BPM para integrar os processos com as aplicações existentes nas empresas. Essa integração elimina procedimentos manuais, sujeitos a erros e atraso, em que um usuário precisa copiar dados de um sistema para outro para dar andamento a um processo. 10. Cloud Computing Com a sofisticação das arquiteturas de aplicações corporativas, o trabalho de TI passou a ser dominado significativamente pela gestão dos recursos computacionais, ao invés de se focar em soluções para atender as necessidades de negócio das empresas. As equipes têm de se preocupar com a capacidade do hardware, controle de versão das aplicações, tratamento de problemas técnicos, entre outras questões. Além disso, há menos tempo para entender o negócio e como as aplicações podem ser exploradas e evoluídas para maximizar sua utilidade. Como alternativa a este modelo, e ao alto custo de aquisição, alguns fornecedores passaram a oferecer suas aplicações como serviços hospedados em datacenters próprios, terceirizando toda a operação. O cliente paga uma assinatura que pode variar de acordo com as features contratadas como volume de acesso e disponibilidade, e precisa garantir que tem uma conexão de rede com throughput suficiente para atender ao uso da aplicação. O nome “cloud” (do inglês, nuvem) veio do símbolo utilizado para indicar a rede exterior às empresas, onde se tem conhecimento “nebuloso” sobre as interligações. Inicialmente, estas aplicações eram instaladas em grandes servidores compartilhados por vários clientes dos provedores de aplicações, mas isto criava problemas de escalabilidade e preocupações com a privacidade dos dados. Os clientes compartilhando uma instalação não desejavam que as demandas de outros o prejudicassem, queriam uma garantia de performance equivalente a que teriam tendo uma máquina própria e não aceitavam o risco de
- 8. uma falha no sistema expor suas informações aos demais “vizinhos”. As primeiras soluções cuidavam de virtualizar o ambiente de cada cliente, o que garantia o isolamento e permitia a transferência para outro hardware com interferência mínima, mas a evolução da tecnologia transformou a virtualização em “unidade” de alocação de recursos, e hoje há uma abstração quase completa entre os recursos físicos e os utilizados pelas aplicações hospedadas, permitindo uma grande escalabilidade e isolamento de uso. Na Figura 6, temos uma comparação das arquiteturas utilizadas nas corporações, desde o mainframe até a computação em nuvem, no que diz respeito a facilidade de uso pelos usuários e a capacidade de escalabilidade e compartilhamento de recursos oferecida por cada uma delas. Figura 6. Evolução da tecnologia 11. Referências http://blog.smartdogservices.com/eai-with-webservices-is-not-soa/ http://blog.softwareadvice.com/articles/enterprise/software-history-pt1-1082411/ http://en.wikipedia.org/wiki/Minicomputer http://en.wikipedia.org/wiki/Monolithic_application http://en.wikipedia.org/wiki/Time-sharing http://en.wikipedia.org/wiki/VisiCalc http://ovir.icp.ac.ru/corba/books/Teach14/ch01/ch01.htm#Heading2 http://plato.stanford.edu/entries/computing-history/ http://sqlmag.com/cloud/cloud-really-just-return-mainframe-computing http://stage.reflectsoftware.com/SOA/Enterprise%20Integration%20EAI%20vs.%20SOA%2 0vs.%20ESB.pdf http://web.mit.edu/15.566/spring98/notes/class12.pdf http://www.academia.edu/2777755/Benefits_and_Drawbacks_of_Cloud- Based_versus_Traditional_ERP_Systems http://www.bpminstitute.org/resources/articles/eai-bpm-and-soa