“Qual a diferença de SOA para algo que já se fala ha muito tempo: programação (e arquitetura de aplicações) orientada a objetos (e/ou componentes)?” Esse (primeiro) comentário no nosso blog (Obrigado Mário!) me levou a entender que a visão sobre o que é uma arquitetura orientada a serviço (SOA) tem ainda não está consolidada, nem entre clientes, nem entre fornecedores. Para resolver isso resolvi criar um item 1 ½ para tentar explicar melhor esse tópico.
Quando desenvolvi meu primeiro sistema (num Apple II+, no bom e velho BASIC) tive muito trabalho, como todos que trabalharam com essa linguagem, para controlar uma quantidade imensa de GOTO’s e JUMP’s dentro do código. E não passava de um mero sistema de automação de oficina eletrônica (daquela época que as TVs apresentavam alguns problemas por ano). Mas foi exatamente assim que surgiu a programação: SEQUENCIAL. Um bloco único de código de executava do início ao fim a finalidade do programa.
Nessa época, a cadeia de valor das empresas ainda era muito restrita. Mesmo os mainframes dessa época trabalhavam com sistemas focados em uma única área: folha de pagamento, controle de estoque, etc.
Logo depois inventaram uma revolução: functions ou procedures. A programação PROCEDURAL foi um grande marco na computação: a possibilidade de reutilizar funções dentro do mesmo programa era algo incrível. Não precisávamos mais gerenciar aqueles laços de GOTO que eram responsáveis por boa parte do bugs.
Mesmo assim, com o aumento da complexidade dos sistemas, a quantidade de linhas de código levou à conclusão que seria mais fácil arrumar uma forma de deixar essas funções em módulos (vários arquivos fonte) que, em tempo de compilação, seriam resolvidos. Chegávamos ao estado da arte (na época): a programação MODULAR.
Esta ainda começou a evoluir de forma espantosa: primeiro as bibliotecas de funções de vinculação estática (em tempo de compilação, as .LIB) e depois bibliotecas de vinculação dinâmica (as conhecedidas .DLL). Naquela época não haveria mais para onde evoluir.
Neste momento da história as cadeias de valor das empresas começaram a ficar mais complexas, demandando, além de sistemas mais complexos, maior agilidade por parte do analistas e desenvolvedores.
Foi no início dos anos 90 quando apareceu um conceito que quebraria alguns paradigmas: A PROGRAMAÇÃO ORIENTADA A OBJETOS. Este era um conceito dos anos 60 que ainda não tinha tido espaço para implementação. A POO tinha como enfoque unidades de programação discretas (objetos) ao invés da programação estruturada normal. O foco da programação estruturada sempre foi a estrutura (óbvio) enquanto a POO se preocupava mais com o comportamento e com os dados. Fazendo um comparativo com a estória da evolução da eletrônica, chegávamos na era dos circuitos integrados: unidades específicas de processamento com comportamento definido, entradas específicas e saídas dependentes dos estados das entradas.
A POO já possibilitava um grande aumento da produtividade e reuso de software mas, para nossa infelicidade (ou felicidade) agora tínhamos a necessidade de fazer com que programas distintos conversassem entre si.
Aqui as cadeias de valor começaram a demandar maior troca de dados entre os diversos sistemas para agilizar os processos de negócios e tornando as empresas mais competitivas.
Entra em cena neste momento o EAI (Enterprise Application Integration). Um conjuntos de princípios arquiteturais e ferramentas (ou middleware) para promover a comunicação entre aplicativos distintos. Dentre as ferramentas destacam-se os MOM (messaging oriented middleware), camadas de software que se encarregavam das complexidades de transmitir uma mensagem da origem ao destino. Inicialmente a infra-estrutura de EIA trabalhava com integração ponto-a-ponto, o que não representava grande problema quando trabalhávamos com um número pequeno de entidades, como na figura 1 abaixo.
O sistemas de estoque tem duas interfaces: uma para o sistema de folha de pagamento (I1) e outra para o sistema de contabilidade (I6), os outros dois sistemas têm também duas interfaces cada. O número total de interfaces nesse cenário é de (somente) seis!
O problema aconteceu quando um grande número de aplicações com necessidades de intercomunicação começou a aparecer. O número de interfaces começou a ficar inviável.
A grande preocupação era o crescimento exponencial do número de interfaces. Para n aplicações, são necessárias n*(n-1) interfaces. Isso signifca que para integrar 5 sistemas, conforme a figura 2, são necessárias 5*(4)= 20 interfaces. Já para integrar 20 sistemas (o que é uma quantidade razoável de sistemas para uma empresa de médio/grande porte) são necessárias 380 interfaces!
Mais uma vez, as mentes brilhantes da computação resolveram essa complexidade de uma forma espetacular: a criação de um modelo HUB AND SPOKE. A figura 3 representa esse modelo onde, um componentes central de middleware é responsável pela transformação, mediação e roteamento das mensagens.
Esta solução prometia durar muito tempo. E durou! Os conhecidos integradores ou brokers desempenharam um papel fundamental por muitos anos, integrando sistemas de todos os tipos.
A diversidade de tecnologias suportando as cadeias de valor em conjunto com a necessidade de interconexões extra-empresa levaram à criação de um modelo mais flexível de integração entre aplicações: a CORBA.
Uma outra tecnologia importante começou a nascer: a CORBA (Common Object Request Broker Architecture). Corba é a arquitetura padrão criada pelo Object Management Group (OMG) para simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software encontradas, a CORBA atuava de modo que os objetos (componentes dos softwares) pudessem se comunicar de forma transparente ao usuário, e o mais transparente possível também para o desenvolvedor.
A CORBA definia o ORB (Object Request Broker) como um módulo intermediário entre cliente e objeto, sendo responsável em aceitar a requisição do cliente, enviá-la para o objeto competente e, assim que disponível a resposta, entregá-la para o cliente. Definia também a IDL (Interface Definition Language), uma linguagem baseada em C++ que não possuia algoritmos nem variáveis, ou seja, puramente declarativa independente da linguagem de programação utilizada para acessá-la. Possibilitava a interoperabilidade entre os diversos sistemas, visto a separação que é definida entre interface e execução. A interface de cada objeto é definida de forma bastante específica, enquanto sua execução (código fonte e dados) permanece oculta para o resto do sistema.
Com o advento da linguagem Java os conceitos de CORBA ainda foram utilizados para implementar a invocação remota de métodos (RMI – remote method interface). RMI eram formas de invocar componentes Java existentes em outras máquinas. A grande vantagem era que a RMI desonerava o programador da complexidade dessa programação.
A figura 4 demonstra a facilidade que o modelo de invocação remota trouxe. O programador (usuário) se preocupada basicamente com o desenvolvimento da aplicação enquanto a infra-estrutura CORBA e a ferramenta de desenvolvimento se encarregavam da comunicação.
O modelo RMI foi amplamente implementado quando a linguagem Java foi atualizada para sua versão corporativa: J2EE (Java 2 Enterprise Edition). A invocação de EJB (Enterprise Java Beans) sempre utilizou uma infra-estrutura de RMI. Os EJB eram abtrações de estados (session beans) e de dados (entity beans).
Quando a cadeia de valor das empresas chegou à internet a linguagem JAVA ganhou importância com sua afinidade com esse ambiente. Especialmente quando a internet deixou de ser uma vitrine e começou a ser efetivamente um canal de negócios.
A arquitetura J2EE também implementou diversos mecanismos de conexão a ambientes não-java como o JCA (Java Connector Architecture) e o JMS (Java Messaging Services) e esses, até então, estão suprindo as necessidades de integração da plataforma Java.
Entretanto, alguns fatores de negócio estão ganhando importância, demandando uma nova visão de tecnologia:
• Necessidades de redução de custos com manutenção de aplicações;
• Demandas de negócio cada vez mais complexas o que gerando aplicações igualmente complexas;
• Competitividade obrigando as empresas a reduzir o time-to-market de seus produtos e serviços;
• Necessidades regulatórias que demandam acesso mais complexo às infomações.
Para atender a esses novos princípios foi concebida a arquitetura orientada a serviços – SOA.
João Luiz Pereira Junior
Fez uma síntese incrível de tantos acontecimentos importantes. Era a visão geral que eu estava procurando. Primeira vez que estou acessando o site e já gostei. Parabéns!
Posted by: Luciano | June 01, 2010 at 06:13 PM