Rumo às tecnologias de objetos e de componentes distribuídos
|
Resumo A CELEPAR está desenvolvendo um projeto chamado "Rumo às Tecnologias de Objetos e de Componentes Distribuídos", cujo objetivo é planejar e iniciar a incorporação dessas tecnologias ao seu processo de desenvolvimento de sistemas. Vinculada a esse projeto está a minha participação no Programa de Mestrado em Informática Aplicada da PUC-PR, que me permite realizar diversos estudos a respeito de arquitetura e metodologia para o desenvolvimento de sistemas distribuídos robustos e escaláveis. Espera-se como um dos resultados dessas atividades (projeto da CELEPAR e mestrado) ampla divulgação das novas tecnologias em estudo, que se dará por meio de palestras, cursos, mentoring e uma série de artigos veiculados regularmente no Bate Byte. Este é o primeiro e apresentará dois assuntos: o contexto no qual se insere o projeto da Celepar; e componentes de software. A contextualização do projeto pretende situar o leitor no tema abordado através de uma síntese sobre a evolução da arquitetura dos sistemas de informação, partindo do momento marcado pelo domínio dos mainframes e chegando até os sistemas distribuídos de múltiplas camadas. Obviamente, quem conhece bem essa história deve ignorar a primeira seção do artigo e concentrar-se na segunda, que trata de componentes. Nas edições futuras do Bate Byte falaremos sobre outros assuntos de interesse para o projeto, tais como servidores de aplicação, persistência de objetos, processo de desenvolvimento de software, casos de sucesso, entre outros. Com relação aos servidores de aplicação, daremos especial atenção aos monitores de transação e aos gerenciadores de filas. Esperamos que você goste desta série de artigos e que ela cumpra o seu objetivo, que é o de divulgar algumas das novas tecnologias em estudo na CELEPAR. 1. O contexto do projeto Durante mais de duas décadas a maioria absoluta dos sistemas de informações corporativos residiu em mainframes. Uma das principais características desses ambientes era a centralização dos dados e dos processos. Era mais fácil administrar, controlar acesso, sintonizar a performance e prestar suporte técnico em um ambiente centralizado. No entanto, sua flexibilidade era pequena, devido à utilização de tecnologias proprietárias; o custo era muito elevado para solucionar problemas de pequeno e médio porte, de forma que somente as grandes empresas eram capazes de pagar; a qualidade do serviço ficava abaixo das expectativas dos usuários, em virtude das limitações da tecnologia de interface dos aplicativos e, também, da falta de liberdade do usuário para manipular seus dados. Todo esse contexto aliado à evolução da tecnologia de redes e ao surgimento de softwares robustos para comporem a infra-estrutura dos ambientes distribuídos, tais como sistemas operacionais e sistemas gerenciadores de bancos de dados, causou a primeira mudança de foco na área de sistemas computacionais: foi a transição de aplicações monolíticas para aplicações cliente/servidor 2-camadas, também conhecidas como fat client ou departamentais. As principais características desse tipo de aplicação, que é muito utilizado atualmente, são as seguintes: menos de 100 usuários simultâneos, 1 ou 2 servidores homogêneos que não interagem, distribuição geográfica a nível de campus, baseia-se em SQL e stored procedures, e processa boa parte da lógica do negócio no lado cliente. Certamente, essa arquitetura teve sucesso porque soluciona muitos dos problemas presentes no ambiente mainframe, mas também apresenta sérias limitações, que foram evidenciadas através da própria lista de características. A conseqüência natural disso foi o surgimento de demanda por aplicações cliente/servidor corporativas, ou seja, aplicações com as qualidades providas pela arquitetura cliente/servidor e com a robustez exigida por sistemas que integram toda a corporação. Para atender essa demanda, estamos entrando numa nova fase de transição. Agora, o foco está mudando da arquitetura cliente/servidor 2-camadas para 3-camadas, também conhecida como n-camadas, fat server ou corporativa. As principais características desse tipo de aplicação, que tende a se tornar muito utilizado, são as seguintes: possibilidade de atingir milhões de usuários, múltiplos servidores heterogêneos interagindo com freqüência, ampla distribuição geográfica, baseia-se em componentes e mantém a lógica do negócio em servidores independentes, situados nas camadas intermediárias. Justamente por esta razão, diz-se que na arquitetura 3-camadas os processos são cidadãos de primeira classe, pois podem ser distribuídos e gerenciados de forma independente do banco de dados e da interface com o usuário [5]. Como essa transição está apenas começando, ainda há muito o que pesquisar e estamos especialmente interessados nesse assunto. Um dos nossos objetivos é propor uma metodologia consistente para o desenvolvimento de sistemas distribuídos robustos e escaláveis, baseada nos componentes arquiteturais sofisticados que estão à nossa disposição. Segundo Coulouris [4], um sistema distribuído é uma coleção de computadores autônomos ligados por uma rede e equipados com softwares distribuídos. Estes softwares permitem que os computadores coordenem suas atividades e compartilhem os recursos do sistema (hardware, software e dados). Os usuários de um sistema distribuído bem projetado deveriam percebê-lo como uma facilidade computacional única e integrada, embora ele possa estar implementado por múltiplos computadores em diferentes locais. A seguir, apresentaremos uma comparação entre as arquiteturas cliente-servidor 2-camadas e 3-camadas, a fim de demonstrar a superioridade desta última e de justificar o desenvolvimento de sistemas distribuídos robustos e escaláveis.
Descrevemos, anteriormente, algumas características básicas que permitem diferenciar sistemas 2-camadas de 3-camadas: número de usuários, número de servidores, heterogeneidade e interatividade dos servidores, distribuição geográfica, entre outras. No entanto, não discutimos as vantagens e desvantagens de cada arquitetura. Isto será feito agora. Antes, porém, precisamos esclarecer um conceito. A expressão 3-camadas refere-se à quantidade de camadas em que o software está logicamente dividido, significando que a interface do aplicativo está nos clientes, o acesso e a atualização dos dados ocorre nos servidores de dados e a lógica da aplicação está separada desses dois elementos, nos servidores de aplicação. No entanto, os componentes do sistema podem estar fisicamente distribuídos em diversos servidores, daí a origem do nome n-camadas. Portanto, arquitetura 3-camadas e n-camadas são sinônimos. Isto esclarecido, vamos comparar as arquiteturas 2-camadas e 3-camadas para entender a importância desta última no contexto de sistemas distribuídos robustos e escaláveis. Esse comparativo será feito com base em características técnicas de ambas as arquiteturas.
2. Componentes de software Componentes de software são unidades binárias cuja produção, aquisição e distribuição são independentes e que interagem para formar um sistema em funcionamento [15]. Vemos com muita freqüência esse conceito sendo confundido com objeto e até mesmo com framework. Vamos esclarecer desde já essa questão. Um objeto é qualquer coisa, real ou abstrata, na qual nós armazenamos dados e as operações que manipulam esses dados. Um framework é uma aplicação reusável, semicompleta que pode ser especializada para produzir aplicações customizadas [6]. Por exemplo, para criar a interface de um aplicativo é necessário instanciar diversos objetos, tais como formulários, botões, caixas de texto, menus, etc. Cada ocorrência de cada um desses elementos na interface do aplicativo é um objeto. O módulo de software que contém as classes prefabricadas a partir das quais se criam esses objetos é o framework de classes (class framework). Diz-se que o framework é uma aplicação porque contém a implementação de diversas classes de objetos que estão relacionadas entre si e pertencem a um mesmo assunto, como por exemplo interface gráfica; diz-se que ele é reusável porque pode ser utilizado na construção de diferentes sistemas; semi-completo porque nunca implementa tudo o que seria possível; e customizável porque admite que o desenvolvedor estenda suas funcionalidades. Existem frameworks em diversas áreas, tais como acesso a banco de dados, persistência de objetos em ambiente relacional, criação de interface gráfica, gerenciamento de coleções de objetos, etc. Componentes, objetos, frameworks e distribuição são conceitos bem diferentes que podem ser combinados. Por exemplo, objetos distribuídos podem ser baseados em componentes, mas não têm que ser; ou podem ter características herdadas de frameworks, mas não precisam ter. Da mesma forma, componentes podem suportar objetos ou distribuição, mas não são obrigados. O uso de componentes é uma atitude natural em qualquer disciplina de engenharia madura, pois aumenta a produtividade do processo de fabricação e garante a qualidade do produto por meio da reutilização de elementos que já foram amplamente testados e que embutem uma série de funcionalidades importantes como segurança, persistência, entre outras. Em compensação, a heterogeneidade dos ambientes de execução desses componentes é um fator que poderia diminuir a possibilidade de distribuí-los. Uma das maneiras de evitar esse problema, que afeta tanto os clientes quanto os fornecedores de componentes, é a criação de padrões. Nesse sentido, existem atualmente três grandes forças no mercado. A OMG (Object Management Group), com o seu padrão CORBA [9, 12, 13], que atua sob uma perspectiva corporativa. A Microsoft, com o seu padrão COM [2, 8, 12], que atua sob uma perspectiva desktop. E a Sun, com o seu padrão Java [10, 11, 14], que atua sob uma perspectiva Internet. Todos os concorrentes tentam aceitar a existência dos outros, fazendo expansões e oferecendo soluções de ligação (bridging solutions). Um padrão comum seria desejável, mas não parece essencial na medida em que o mercado para cada um deles seja suficientemente grande e exista tecnologia de integração. Atualmente, a maior parte dos esforços de padronização na área de componentes está ou a nível de "barramento" (bus) ou a nível interno dos componentes, mas é provável que o mercado de componentes de domínio específico (bancos, serviços médicos, automação industrial, etc.) se torne o mais lucrativo. Algumas questões bastante presentes quando se fala de componentes são as seguintes: Como pode ser descrita a interação abstrata entre componentes? Como podem ser garantidas propriedades de sistemas críticos na presença de componentes arbitrários de terceiros? Como a performance pode ser garantida? Acredita-se que a resposta esteja nos frameworks de componentes [6, 12, 15] (component framework). Apesar da similaridade de nomes, das visões quase idênticas e dos princípios de construção superficialmente parecidos, os component frameworks são muito diferentes dos class frameworks. Consistem de um conjunto de interfaces e regras de interação que definem como os componentes acoplados ao framework podem interagir. Opcionalmente, podem oferecer uma implementação que força parcialmente essas regras de interação. Um bom exemplo de component framework é o próprio CORBA: contém inúmeras especificações de interfaces e de regras de intereção entre seus componentes, entretanto, não estabelece políticas de implementação. Cada fornecedor é livre para construir seu produto como bem lhe convier, desde que respeite as interfaces e as regras de interação. Vale enfatizar que os class frameworks possuem implementações de classes, enquanto os component frameworks apenas descrevem de forma abstrata a interação que deve existir entre componentes de software.
As questões que devem ser respondidas nesta seção são as seguintes: quais são os benefícios de se utilizar componentes de software? Por que não comprar produtos prontos (ERP – Enterprise Resource Planning: sistemas integrados de gestão empresarial)? Por que não fazer software totalmente sob medida? Por que não fazer software baseado em frameworks? Produzir software sob medida é muito caro. Além disso, se compararmos o tempo requerido para a construção do produto e o prazo dentro do qual ele se torna obsoleto, podemos descobrir que a sua vida útil é mais curta do que a necessária para compensar seus custos. Devido a essas características, uma atitude comum e compreensível é a terceirização da produção de software sob medida, através de contratos com preço fixo, com o objetivo de limitar os riscos financeiros. Isto pode resolver o problema do risco financeiro, mas não o do tempo necessário para distribuir o produto (time-to-market risk). Para solucionar o risco do prazo existe uma forte tendência de uso de software padrão (ERP), ou seja, pacotes de software que sofrem pequenos ajustes para se adaptarem às necessidades reais do comprador. Um aspecto positivo desta abordagem é que a manutenção, a evolução e a interoperabilidade do produto são preocupações do vendedor do pacote. Entretanto, um dos problemas desta alternativa é a necessidade de reorganizar os processos de negócio da empresa que está adquirindo o produto. Outro, é o fato de que se o software é padrão todos aqueles que o comprarem terão o mesmo produto, ou seja, não pode ser utilizado como um diferencial competitivo. Em terceiro lugar, software padrão não é controlado localmente, o que significa que ele não é ágil o suficiente para adaptar-se rapidamente às mudanças de necessidades. Em 1996, o correio da Austrália, uma grande empresa de estrutura federativa, decidiu usar a solução integrada R/3 da SAP. O modelo hierárquico de autorização de acesso imposto pelo R/3 conflitou com o conceito de organização federada do correio, que delega muita responsabilidade e autoridade aos seus membros. Quando a SAP foi questionada sobre a possibilidade de alterar esse aspecto do R/3, respondeu o seguinte: "Nossos sistemas implementam as melhores práticas – por que vocês querem divergir delas?" [15]. Este exemplo demonstra que uma solução padronizada pode forçar mudanças drásticas na cultura e na operação de uma organização. O desenvolvimento de software baseado em bibliotecas de classes e frameworks requer profissionais qualificados e altamente treinados, pois eles precisam conhecer muito bem a estrutura do produto que servirá de base para a sua criação se quiserem reutilizar de maneira eficiente o máximo de código possível. Além disso, os frameworks raramente visam composição com produtos de terceiros. A combinação de frameworks orientados a objetos tradicionais é difícil. O Taligent’s CommonPoint tentou fazer isso, mas devido a uma arquitetura geral subdesenvolvida não atingiu seu objetivo. Nesse projeto foram criados 100 frameworks, 2.000 classes públicas, 2.000 não públicas e 53.000 métodos. Para que se tenha uma idéia do quanto isso é grande e complicado basta comparar com a API do Windows: ela suporta cerca de 1.500 chamadas [15]. A utilização de componentes de software representa uma abordagem intermediária em relação às outras três (software sob medida, ERP e framework). Embora os componentes sejam padronizados, o processo de montagem dos componentes possibilita customização significativa. Alguns componentes podem ser feitos sob medida a fim de atender requisitos específicos ou de criar vantagens estratégicas. É apropriado que se delegue a construção de componentes a pessoas altamente especializadas, mas a montagem deles, isto é, sua composição e integração, não deve ficar restrita a uma elite.
A camada intermediária na maioria das aplicações 3-camadas não é implementada como um programa monolítico, mas sim como uma coleção de componentes. Cada componente automatiza uma função de negócio relativamente pequena. Freqüentemente os clientes combinam diversos componentes dentro de uma única transação de negócio. Um componente pode chamar outros componentes para auxiliá-lo a responder uma requisição. Além disso, alguns componentes podem agir como gateways para encapsular aplicações legadas rodando em mainframe. Quando se projeta a camada intermediária de uma aplicação baseada em componentes, obtêm-se os seguintes benefícios:
Existem dois tipos de componentes que podem ser utilizados na camada intermediária de uma aplicação:
COM é um exemplo de ambiente para objetos stateless e CORBA suporta ambos os tipos de objetos, stateless e stateful, embora a maioria dos ORBs padrão CORBA, hoje, sejam stateless. O COM supera parcialmente sua limitação a objetos stateless usando Monikers [12]. Um moniker é um objeto que age como um apelido persistente para outros objetos. Monikers podem prover apelidos para nomes de arquivos distribuídos, consultas a bancos de dados, um parágrafo em um documento, um intervalo de células em uma planilha eletrônica, um computador remoto, etc. O nome torna-se um "objeto moniker" que implementa interfaces relacionadas a nomes. Os monikers foram criados para solucionar um problema do OLE 1: hardcoded links. Em OLE 1, os links eram armazenados usando pathnames absolutos e poderiam quebrar toda vez que alguém mudasse o documento fonte de lugar. Os monikers adicionaram mais um nível de indireção que solucionou parcialmente o problema. Os objetos cliente enviam requisições para os componentes usando nomes lógicos ao invés de endereços físicos. O middleware mapeia esses nomes lógicos para os nomes físicos correspondentes e garante a entrega da mensagem. O modelo de programação do middleware determina se serão chamados objetos ou serviços. O middleware pode oferecer as seguintes alternativas de troca de mensagens.
Sempre que surge uma nova tecnologia, como componentes de software, os usuários potenciais desejam saber quem está investindo nela e o quanto está investindo, a fim de avaliar suas chances de sucesso. Assim sendo, gostaríamos de descrever algumas ações que vêm ocorrendo no Brasil e no mundo dentro dessa área. Comecemos pela OMG (Object Management Group), a instituição responsável pela padronização da tecnologia de objetos distribuídos no mundo, que conta com centenas de associados, entre os quais se destacam grandes empresas produtoras de software, tais como IBM, Oracle, Microsoft, Sybase, BEA, Inprise, Sun, entre outras. Além de criar padrões relacionados à infra-estrutura necessária para distribuição de objetos, a OMG também padroniza objetos de domínios específicos através dos seus grupos de interesses especiais (SIG – Special Interest Group). Atualmente, os esforços mais notáveis concentram-se nas áreas financeira, médica e de telecomunicações. Informações sobre essas atividades podem ser encontradas no site da OMG [9]. Outra iniciativa interessante na área de componentes de software é o projeto SanFrancisco da IBM. Ele oferece aos desenvolvedores de aplicação uma infra-estrutura para distribuição de objetos e um conjunto de componentes de aplicação que podem ser expandidos e aprimorados a fim de obter diferencial competitivo. A figura a seguir [7] mostra a arquitetura do produto. O nível mais baixo, chamado Foundation, provê a infra-estrutura e os serviços necessários para construir aplicações corporativas em ambiente distribuído, orientado a objetos e multi-plataforma. Muitos dos serviços se baseiam nas definições da OMG. A segunda camada, chamada Common Business Objects, provê definições de objetos de negócio comumente utilizados que podem servir de base para a integração de aplicações, tais como Business Partner (Parceiro), Address (Endereço), entre outros. O nível mais alto da arquitetura, chamado Core Business Process, provê objetos de negócio e lógica de negócio padrão para domínios específicos como Contas a Pagar (AP) e Contas a Receber (AR), Gestão de Pedidos, Gestão de Almoxarifado e Contabilidade Geral (GL). O SanFranciso se propõe a auxiliar a construção do lado servidor de aplicações baseadas em Java.
O Brasil também está procurando tirar proveito da tecnologia de componentes de software. O DATASUS juntamente com o Centro de Informática em Saúde da Universidade Federal de São Paulo (CIS-EPM/UNIFESP), o Hospital de Clínicas da Universidade de São Paulo, as empresas de Processamento de Dados de Belo Horizonte (PRODABEL) e de Porto Alegre (PROCEMPA), o Instituto do Coração do Hospital de Clínicas da Faculdade de Medicina da USP, o Hospital de Clínicas de Porto Alegre (HCPA-UFRGS) e a Sociedade Brasileira de Informática em Saúde (SBIS) fundaram o CCS-SIS (Consórcio de Componentes de Software para Sistemas de Informação em Saúde) a fim de criar componentes de software específicos para a área de saúde capazes de atender as necessidades das aplicações do SUS (Sistema Único de Saúde), da área de seguros-saúde e de empresas privadas [2]. O processo de especificação dos componentes é aberto e segue os moldes dos comitês de padronização ANSI (Americam National Standards Institute). Os produtos desse consórcio são de domínio público e são aderentes ao padrão CORBA. Atualmente, já existem mais de 20 membros filiados ao consórcio entre empresas, hospitais universitários, hospitais, universidades, centros de pesquisa e secretarias de saúde estaduais e municipais. Referências Bibliográficas
|
 |