Quanto mais nova e mais sofisticada se torna o sistema de informação do chão de fábrica, técnicas usadas para desenvolver programas para ela devem mudar. Em razão de criar softwares para esses sistemas , programas firmam a necessidade de métodos melhores para organizar suas mercadorias e produtos. Conseqüentemente o próximo passo lógico esta vindo da tecnologia de Objetos Orientados que vem amadurecendo desde 1980 ate se integrar ao Modelo de Componente dos dias atuais. Utilizando esse modelo, componentes reutilizáveis que são escritos apenas uma vez e rodados em qualquer lugar, tem o potencial de revolucionar a indústria de softwares.
Sob a influência dessa tecnologia , fornecedores de softwares para a indústria de corrugados vão ser capazes de aproveitar melhor o progresso da explosão da comunicação. Para o usuário final, isso irá resultar numa organização mais rápida do sistema de informação da fábrica, menos ruptura nas operações de produção e melhor retorno de investimento a longo prazo em todos os sentidos.
Para podermos entender em que ponto se encontra a tecnologia servidor cliente nos dias atuais, primeiro é necessário analisarmos a evolução das redes de computador. Arquitetura cliente servidor é comumente descrita em termos de camadas. Cada camada representa um paradigma em tecnologia da computação que resulta em melhores níveis de serviços usuários finais.
O modelo terminal de interatividade de computação foi o mais novo a ser largamente adotado. Nesse modelo de computação toda informação e programas residiam em uma única máquina ou host. Isso fez com que os hosts rodassem a interface do usuário assim como o banco de dados e aplicações empresariais.
Os usuários interagem com essa máquina através de um terminal que tem um pouco de inteligência. Ele sabe apenas como receber telas em respostas a digitação e manda-las de volta ao host. [Valesky 99]
Nos anos 80, computadores pessoais se tornaram populares. PCs eram atrativos porque eram menos caroS e mais responsáveis do que o mainframe , não necessitavam de tempo de processamento , além de ter dados aos usuários o sentido de liberdade e autoridade , fornecendo ‘inteligência’ local ou poder de processamento. Um usuário de PC poderia trazer uma série de informações para uma aplicação e manipula-las localmente por horas sem dispor de qualquer requerimento do sistema de mainframe centralizado. No início os pcs eram unidades isoladas, mas com o passar do tempo eles foram integrados a redes. Eventualmente muitas organizações começaram a construir novos sistemas de informação nos pcs ao invés de faze-lo no mainframe. Ao mesmo tempo, o controle do banco de dados dedicado começou a aparecer. A combinação desses dois elementos: o servidor de banco de dados e o PC cliente são referenciados como sendo as duas camadas ou então arquitetura cliente – servidor. [Valesky 99]
Num sistema de duas camadas, cliente-servidor, a interface que roda no cliente e no banco de dados residem em servidores separados. O servidor nesse cenário é chamado de servidor de banco de dados. A aplicação rodando na maquina do cliente contem tanto a descrição lógica que é o código necessário para construir e rodar a interface do usuário, e as regras de negócios que é a lógica que administra como as informações são manipuladas. Sistema de duas camadas ainda são muito comuns nos dias de hoje..
Enquanto essa é uma solucao muito flexivel, problemas aparecem quando a necessidade para a atualização dos clientes e banco de dados acontecerem simultaneamente. Todas as maquinas devem ser desligadas para atualização e clientes ou servidores que estiverem por trás desse softwares não serão capazes de rodar ate que a atualização seja terminada. O exemplo a seguir vai ajudar a ilustrar a questão que surgiu quando mudanças foram necessárias num sistema de duas camadas. [Valesky 99]
Nos tem sido dada a tarefa de implementar uma aplicacao que simplesmente compute a taxa de pagamento para todos os nossos funcionários. Nos encontramos com nossos amigos contadores e determinamos que a lógica do negocio que compensa é como segue:
- Entra-se com a taxa de pagamento, horas trabalhdas e o numero do empregado.
- Calcula-se o pagamento para o empregado.
- Gera-se uma estrutura de sql para atualizar o banco de dados.
Nós então implementamos nossa aplicação , a instalamos em 50 diferentes desktops, e vamos pra casa. Assim que chegamos no escritório na manhã seguinte nos deparamos com vários empregados que trabalham por hora, furiosos. Parece que nos esquecemos de um pequeno detalhe na logistica dos negocios. HORA EXTRA !
Depois de perceber esse erro, e culpar o departamento de contabilidade , o programa cliente é reescrito e distribuído para os mesmo 50 computadores novamente. Por um pequeno período de tempo, todos estão felizes. No entanto semanas se passam e é verificado que alguns funcionários que deveriam receber salário fixo, estão recebendo por horas e hora extra trabalhadas. Novamente é necessário mudanças no programa cliente, desligar todos os sistemas em operação, fazer a modificação e redistribuir a aplicação.
Esse simples exemplo ilustra como a inteface do usuário foi desenvolvida para nosso sistema de duas camadas cliente – servidor. Infelizmente esse sistema não nos da a opção de separarmos as especificações de interface. Das regras dos negocios. Tambem nao deixa simplificar o processo de implementacao dessas mudancas. Conseqüentemente, vamos considerar uma arquitetura de sistema de informação que vai reduzir significativamente esses problemas que todos aprenderam a aceitar.
TRÊS CAMADAS
Numa arquitetura tradicional cliente servidor, a aplicação do cliente tem crescido ‘gorda’ porque ela contém a descrição lógica administrando o windows e controlando manipulação, lógica dos negócios administrando algoritimos e regras de negócios, e manipulação de informação administrando conexões do banco de dados e comandos SQL. Numa arquitetura de 3 camadas , o cliente apenas contém uma descrição lógica o que faze dele um cliente ‘magro’.. [Thomas 98]
Essa inovação, assim como na inovação de duas camadas, usa o banco de dados como último repositório de informações e o cliente permanece responsável de fornecer a lógica da interface do usuário. As regras de negócio , no entanto, são separadas numa camada intermediária que é conhecida como servidor de aplicação. Ao invés de ter a máquina cliente atualizando o banco de dados diretamente, o cliente faz uma chamada ao servidor de aplicação, que então atualiza o banco de dados. Isso liberta desenvovedores dos detalhes de baixo nivel de manusear transações , threads de execução e balanceamento de carregamento do sistema. O desenvolvedor de aplicação pode concentrar-se na lógica dos negócios deixar os detalhes de administração de procesamento de informação para o sistema framework. [Valesky99]
A inovação de 3 camadas para calcular o problema de pagamento que nos discutimos antes seria baseado de um cliente que tivesse a mesma interface do usuário que no sistema de 2 camdas. No entanto, ao invés de fazer o cálculo de pagamento para o banco de dados armazenar o cliente simplesmente chamaria a função chamada.
atualizar_salario()
O cliente passa essa rotina fornecendo todos os parâmetros do empregado. Essa rotina executa a lógica dos negócios para determinar o pagamento do empregado e já atualizada o banco de dados devidamente. Agora, quando for necessário fazer alguma mudança na lógica de negocios, apenas a camada intermediária precisa ser alterada. Como você pode imaginar essa inovação simplificou a maneira como a informação é processada pois apenas precisa ser feita num so lugar.
Mas que tipo de implementação irá permitir que nos criemos essa distribuição de programas quando considerarmos que ambiente de computação corporativa possui mainframes, mid frames, pcs, laptops e outras aplicações eletrônicas ??? Isso sem mencionar na variedade de fornecedores que existem numa fábrica de caixas. Mas nossa indústria não esta sozinha.
Fábricas de caixa devem ser livres para adquirir o melhor processo de fabricação de diferentes fornecedores e intregra-los no sistema de redes já existente, suportando que diversas plataformas se produtos se comuniquem e operem de maneira relacionada.
MODELO BASEADO EM COMPONENTES
Um novo tipo de aplicação distribuída sera necesário para possibilitar essas ‘conversações’ entre sistemas distintos. Muitos fornecedores líderes de vendas tem cooperado para criar um novo paradigma chamado de Modelo de Componente. Porem, antes de mais nada, vamos definir o que vem a ser um componente
Um componente é um bloco de programação reutilizável : um pedaço pré-fabricado de códigos de aplicações encapsuladas que podem ser combinadas com outros componentes e com código escritos manualmente para rapidamente produzir uma aplicação customizada. Desenvolvimento baseado nesse modelo permite o uso e reuso. [Thomas 98]
Componentes vem numa grande variedade de tamanhos e formatos. Ele pode ser muito pequeno. Pode tb ser implementado como um serviço aplicação complexa como uma função que controla pagamentos. A arquitetura que vai guiar o seu desenvolvimento e interação entre esses componentes é chamado de Modelo de Componente
Um modelo de componente define a arquitetura básica de um componente , especificando a estrutura de sua interface e os mecanismos de com quem ele irá interagir. O modelo de componente pode fornecer linhas guias para criar e implementar componentes que podem trabalhar juntos para formar uma aplicação extensa. Desenvolvedores de aplicação podem combinar componentes de diferentes fornecedores para construir uma aplicação. [Thomas 98]
Apesar de cada componente adquirido ser um produto padrozinado com suas próprias vantagens , o processo de montagem de cada componente da a oportunidade para customização significantes. Programas modulares também poe um fim ao problema de ciclos de atualizacao massivos. Tradicionalmente, soluções totalmente integradas requerem atualizações periódicas , envolvendo um processo doloroso de migração de banco de dados antigos, compra de equipamentos mais poderosos etc. Num sistema modular de solução, evolução substitui revolução. Atualização individual dos componentes pode ser feita de acordo com a necessidade, ganhando–se enorme potencial. [Szyperski 97]
BENEFÍCIOS
Há diversas áreas chaves em que componentes tecnológicos vão causar impacto no desenvolvimento, implementação, manutenção e atualização para aplicações desenvolvidas. Cada benefício destacado abaixo deve ter um impacto positivo e direto no cenário de retorno dos investimentos para implementação de sistemas para fábricas de papelão.
[Hurwitz 98]
Segundo Hurwitz, o modelo baseado em componentes:
- Viabilizar distribuição de implementação.
Modularidade viabiliza uma completa distribuição de funcionalidades , mantendo integração.
- Permite aos usuários que misturem aplicações integradas .
- Permite estratégia de atualizações diferenciada.
Ao invés de atualizar um pacote inteiro, usuários podem atualizar componentes individuais com significante redução de custo
- Maior versatilidade
Tecnologia desenvolvida baseada técnica de modularidade suportam modelagem, desenvolvimento, construção e testes de programas bem definidos que vão permitir com mais facilidade a criação de aplicações críticas
- Diminui tempo de desenvolvimento.
Custos de desenvolvimento e manutenção de Software são diminuídos mandando componentes que pode ser compartilhados e reusados para outros projetos.
Apesar dos conceitos de modularidade e multiplas camdas estarem presentes por quase uma década , relativamente ainda sao poucas as organizações que a colocaram em uso
Uma aplicação de cliente ‘magro’ é muito mais fácil de ser controlada do que o tradicional cliente – servidor. Muito pouco código é organizado nos sistema clinte. A maioria das aplicações lógicas são organizadas, controladas e mantidas no servidor. Consertos, atualizações , novas versões, e expansões, podem ser administradas num ambiente de administração e controle centralizado Peritos na indústria de softwares sentem que é o futuro do desenvolvimento cliente – servidor. Acreditam que o impacto sera maior do que os banco de dados relacionais.
Como qualquer outra tecnologia de , desenvolvimento baseado em componentes, nao se trata de nada extraordinário. Mas com certeza isso traz algumas novidades para o processo de desenvolvimento que esta diretamente ligado aos problemas inerentes de integração, abrindo as portas para novos sistemas. [Rivas 97]
Sem a sua chegada, desenvolvimento com certeza teria permanecido com sistemas pobres que tendem a falhar em larga escala.Por último, sistemas não poderiam ser mantidos por causa da complexibilidade da lógica dos negócios que tinham crescido sob o escopo de serviços básicos oferecidos no esquema antigo de cliente – servidor. Essa inovação esta tendo um impacto maior no desenvolvimento e organização de aplicações . Esse modelo utiliza técnicas baseadas em componentes para melhorar a utlização de aplicações críticas, que antes constituíam um processo complexo. Como isso começou a se tornar mais definido, e a utilização de programas reutilizáveis passou ser mais adotado, o sucesso completo de cliente – servidor irá começar a avançar. Adotando esses padrões emergentes como procedimento , e no processo , satisfazer os requisitos dos usuários, terá o potencial de economizar milhões de dólares com custo de desenvolvimento.
PARA ONDE VAMOS ?
Como toda tecnologia inovadora, nos temos que nos referir ao modelo componente com cuidado.Para que se possa alcançar a adoção deste modelo em larga escala, um guia deve surgir porque há diferenças sutis entre cada um dos modelos que competem , podendo ser inapropriado implementar diretamente qualquer tecnologia. No entanto, nos achamos que isso é um avanço importante na indústria de computadores por estarem usando esses conceitos no desenvolvimento de sistemas futuros. Atualmente existem duas escolas principais no que se refere a implementacao atual do modelo de componentes. Uma que está sendo dirigida pela Microsoft é chamada de DCOM. A outra é conhecida por JAVA e é liderada por um grupo de empresas incluindo a IBM, Oracle, Sybase , Netscape entre outros. No momento não há preferências entre ambos porque tanto um quanto outro apresentam pontos fortes e também fraquezas.
Estima-se que essa tecnologia de componentes sera largamente adotada nos próximos 3 a 5 anos. Enquanto isso pode parecer pouco para aqueles que adquirem aplicações agora, isso irá dar o que falar quando novas versões e integrações de fornecedores começarem a ocorrer. Isso irá resultar em menos interrupção e melhores retornos para os clientes.
Referências:
[Gilpin 98] Gilpin, Mike. A Market is Born.
Miller Freeman Inc., 1998
[Hurwitz 98] Hurwitz Group, Inc. J.D. Edwards’ OneWorld: Componentization
for Business Advantage. Hurwitz Group Inc. 1998
[IDC 98] Picardi, Anthony C. Beyond Client/Server: Application Paradigms
for the Rest of the Century. IDC 1998
Rivas 97] Rivas, Erick. Enterprise Component Modeling Strategies-ECM clears
the applications bottleneck through component-based development and object-oriented techniques.
Object Magazine Abril de 1997
[Szyperski 97] Szyperski, Clemens. Component Software – Beyond
Object-Oriented Programming. Addison-Wesley, 1997
[Thomas 98] Thomas, Anne. Enterprise JavaBeans Technology-Server Component
Model for the Java Platform. Patricia Seybold Group, 1998
[Valesky 99] Valesky, Tom. Enterprise JavaBeans – Developing
Component-Based Distributed Applications. Addison-Wesley, 1999
