Fonte: www.activedelphi.com.br
Um dos maiores paradigmas da indústria de informática, nos dias de hoje, é o novo conceito de processamento cliente/servidor, onde existe...
uma mudança das aplicações codificadas em segmentos, partes ou componentes. Estas aplicações são separadas logicamente em três camadas: usuário, regras de negócio e dados.
A aplicação está dividida ao longo de linhas locais/remotas de dados, o que torna a infra-estrutura de redes das empresas um dos grandes fatores críticos de sucesso no desenvolvimento e implantação de um sistema. O cliente, tipicamente um PC, fornece a interface gráfica enquanto os servidores fornecem um conjunto de serviços.
Esses componentes, conhecidos como objetos, são distribuídos nas redes gerando um novo paradigma dentro de um já existente: a revolução do cliente/servidor. O resultado final é a quebra das aplicações em componentes, onde a reutilização e o baixo custo de implementação são os grandes benefícios obtidos.
Um objeto é essencialmente um componente com inteligência que opera entre sistemas operacionais heterogêneos, desenvolvido em várias linguagens de programação. Na área de desenvolvimento de sistemas, o conceito de objetos está alterando totalmente a arquitetura, desenvolvimento, empacotamento, distribuição e manutenção de software.
Então, qual a diferença entre um objeto clássico e um objeto distribuído? Um objeto clássico possui propriedades e métodos e é gerado através de uma linguagem de programação como Delphi, C++, VB, entre outras.
Esses objetos fornecem reusabilidade de código através de herança, encapsulamento e polimorfismo, propriedades fundamentais da teoria orientada a objetos. Contudo, esses objetos só vivem dentro de um programa; apenas o compilador que os criou conhece a sua existência.
O mundo externo os desconhece e não tem formas de acessá-los. Um objeto distribuído também é uma classe que pode publicar (tornar disponível) tanto suas propriedades quanto seus métodos, mas a linguagem e o compilador usados para criar objetos distribuídos são totalmente transparentes para a implementação desses. Esses objetos têm uma interface definida onde os compiladores geram um código a mais para serem acessados por outros objetos de forma totalmente transparente, isto é, o invocador desconhece o local do objeto invocado, o sistema operacional que esse executa, podendo estar fisicamente na mesma máquina (processo) ou em alguma máquina remota.
Um dos fatores críticos para a implementação de um sistema com componentes distribuídos é a transparência da sua localização física, podendo operar num processador local, num processo diferente ou num processador remoto. Porém, um componente não pode operar no vácuo, e por isso precisa de uma base denominada "barramento" de objetos distribuídos (ORB - Object Request Broker). Esse barramento oferece serviços que permitem a interligação entre os diversos componentes nas diferentes plataformas. É necessário utilizar esse serviço porque a interação entre componentes é requisito básico para a construção de uma aplicação de negócio. Os componentes estão sempre adicionando novos serviços, que são herdados durante sua compilação ou execução e alcançam altos níveis de colaboração entre si.
Nos dias de hoje, existem na indústria dois grandes padrões para desenvolvimento de objetos distribuídos que separam a interface de um objeto de sua implementação: DCOM (Distributed Component Object Model) e CORBA (Common Object Request Broker Architecture).
Os elementos principais da especificação CORBA são a linguagem de definição das interfaces dos objetos que serão criados e colocados à disposição na rede (IDL - Interface Definition Language) e um repositório (IR - Interface Repository) que representa as interfaces (ou classes) de todos os objetos disponíveis no sistema distribuído.
Como criarmos objetos para CORBA e/ou DCOM? Ambos têm o objetivo de fornecer uma transparência de localização de objetos e sua implementação, o que exige definição de interface entre os componentes. Essa interface deve ser publicada (tornada pública) e serve como mecanismo de ligação e acionamento entre esses componentes. A interface dos componentes é especificada em IDL, uma linguagem puramente declarativa que não define nada sobre a implementação desses componentes.
DCOM, além de separar a interface de um objeto de sua implementação, é uma extensão de COM (Component Object Model), parte da família Windows de sistemas operacionais, baseada na infra-estrutura de OLE e Active X. COM/DCOM é um framework baseado na construção de objetos para desenvolvimento que usa uma variedade de linguagens e ferramentas totalmente independentes de linguagem de programação, sendo parte implícita dos sistemas operacionais da Microsoft Windws NT e Windows 95.
Os fatores para uma comparação entre DCOM e CORBA são suporte para plataforma e linguagem, custo e integração.
Com relação à integração é importante a construção de "pontes" entre CORBA e DCOM, que permitirá distribuir objetos entre servidores e estações na Internet/intranet. O OMG definiu os mapeamentos entre COM e CORBA de tal forma que objetos COM podem invocar objetos CORBA e objetos CORBA invocam objetos COM.
uma mudança das aplicações codificadas em segmentos, partes ou componentes. Estas aplicações são separadas logicamente em três camadas: usuário, regras de negócio e dados.
A aplicação está dividida ao longo de linhas locais/remotas de dados, o que torna a infra-estrutura de redes das empresas um dos grandes fatores críticos de sucesso no desenvolvimento e implantação de um sistema. O cliente, tipicamente um PC, fornece a interface gráfica enquanto os servidores fornecem um conjunto de serviços.
Esses componentes, conhecidos como objetos, são distribuídos nas redes gerando um novo paradigma dentro de um já existente: a revolução do cliente/servidor. O resultado final é a quebra das aplicações em componentes, onde a reutilização e o baixo custo de implementação são os grandes benefícios obtidos.
Um objeto é essencialmente um componente com inteligência que opera entre sistemas operacionais heterogêneos, desenvolvido em várias linguagens de programação. Na área de desenvolvimento de sistemas, o conceito de objetos está alterando totalmente a arquitetura, desenvolvimento, empacotamento, distribuição e manutenção de software.
Então, qual a diferença entre um objeto clássico e um objeto distribuído? Um objeto clássico possui propriedades e métodos e é gerado através de uma linguagem de programação como Delphi, C++, VB, entre outras.
Esses objetos fornecem reusabilidade de código através de herança, encapsulamento e polimorfismo, propriedades fundamentais da teoria orientada a objetos. Contudo, esses objetos só vivem dentro de um programa; apenas o compilador que os criou conhece a sua existência.
O mundo externo os desconhece e não tem formas de acessá-los. Um objeto distribuído também é uma classe que pode publicar (tornar disponível) tanto suas propriedades quanto seus métodos, mas a linguagem e o compilador usados para criar objetos distribuídos são totalmente transparentes para a implementação desses. Esses objetos têm uma interface definida onde os compiladores geram um código a mais para serem acessados por outros objetos de forma totalmente transparente, isto é, o invocador desconhece o local do objeto invocado, o sistema operacional que esse executa, podendo estar fisicamente na mesma máquina (processo) ou em alguma máquina remota.
Um dos fatores críticos para a implementação de um sistema com componentes distribuídos é a transparência da sua localização física, podendo operar num processador local, num processo diferente ou num processador remoto. Porém, um componente não pode operar no vácuo, e por isso precisa de uma base denominada "barramento" de objetos distribuídos (ORB - Object Request Broker). Esse barramento oferece serviços que permitem a interligação entre os diversos componentes nas diferentes plataformas. É necessário utilizar esse serviço porque a interação entre componentes é requisito básico para a construção de uma aplicação de negócio. Os componentes estão sempre adicionando novos serviços, que são herdados durante sua compilação ou execução e alcançam altos níveis de colaboração entre si.
Nos dias de hoje, existem na indústria dois grandes padrões para desenvolvimento de objetos distribuídos que separam a interface de um objeto de sua implementação: DCOM (Distributed Component Object Model) e CORBA (Common Object Request Broker Architecture).
Os elementos principais da especificação CORBA são a linguagem de definição das interfaces dos objetos que serão criados e colocados à disposição na rede (IDL - Interface Definition Language) e um repositório (IR - Interface Repository) que representa as interfaces (ou classes) de todos os objetos disponíveis no sistema distribuído.
Como criarmos objetos para CORBA e/ou DCOM? Ambos têm o objetivo de fornecer uma transparência de localização de objetos e sua implementação, o que exige definição de interface entre os componentes. Essa interface deve ser publicada (tornada pública) e serve como mecanismo de ligação e acionamento entre esses componentes. A interface dos componentes é especificada em IDL, uma linguagem puramente declarativa que não define nada sobre a implementação desses componentes.
DCOM, além de separar a interface de um objeto de sua implementação, é uma extensão de COM (Component Object Model), parte da família Windows de sistemas operacionais, baseada na infra-estrutura de OLE e Active X. COM/DCOM é um framework baseado na construção de objetos para desenvolvimento que usa uma variedade de linguagens e ferramentas totalmente independentes de linguagem de programação, sendo parte implícita dos sistemas operacionais da Microsoft Windws NT e Windows 95.
Os fatores para uma comparação entre DCOM e CORBA são suporte para plataforma e linguagem, custo e integração.
Com relação à integração é importante a construção de "pontes" entre CORBA e DCOM, que permitirá distribuir objetos entre servidores e estações na Internet/intranet. O OMG definiu os mapeamentos entre COM e CORBA de tal forma que objetos COM podem invocar objetos CORBA e objetos CORBA invocam objetos COM.
Nenhum comentário:
Postar um comentário