O modelo de arquitetura CORBA e suas aplicações

ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 157 O modelo de arquitetura CORBA e suas aplicações ANA PAULA GONÇALVES SERRA* Resumo Nos últimos anos, os sistemas de informação nas empresas têm evoluído e adquirido uma importância fundamental. Conjuntamente com a evolução surge a necessidade de integrar diversas tecnologias em ambientes heterogêneos com o objetivo de capturar e difundir informação de forma transparente ao usuário final e com eficiência. Uma das formas mais adequadas para essa integração é a de arquiteturas de objetos distribuídos, devido a isso, apresenta-se neste trabalho a arquitetura Common Object Request Broker Architecture (CORBA) e sua aplicação no desenvolvimento de sistemas de informação nas empresas. Palavras-chave arquitetura, objetos distribuídos, CORBA. Title The CORBA architectural model and its applications Abstract Recently information systems in enterprises have evolved and acquired a basic importance. Together with this evolution there is a need to integrate several technologies in heterogeneous environments in order to catch and disseminate information in a clear and efficient way to final users. One of the most suitable ways of doing this are architectures with distributed objects; thus, we here present Common Object Request Broker Architecture (CORBA) and its applications in the development of information systems in enterprises. Keywords architecture, distributeds objects, CORBA. 1. INTRODUÇÃO Atualmente vivemos em uma sociedade em que o foco principal é a informação. A sociedade de uma forma geral passou por uma grande evolução depois da sociedade industrial e pós-industrial, e atualmente passa por mais uma evolução que é chamada de sociedade da informação. A sociedade da informação é um estágio de desenvolvimento social caracterizado pela capacidade de obter e compartilhar qualquer informação, instantaneamente, de qualquer lugar e da maneira mais adequada [9]. Pode-se considerar que os principais recursos tecnológicos que contribuíram para essa mudança na sociedade foram a descentralização dos sistemas de informação, a descentralização de processamento, a integração de hardware e software, a integração de diversos sistemas de informação com tecnologias distintas, o surgimento de sistemas e padrões abertos e a Internet. Com isso, surgiu a necessidade de desenvolvimento de sistemas de informação que suportem toda essa integração de tecnologias e descentralização dos sistemas de informação. Uma das formas que apóiam o desenvolvimento desse novo conceito de sistemas de informação são as arquiteturas de objetos distribuídos, atualmente um campo de pesquisa em crescente desenvolvimento [6][9]. O principal intuito das arquiteturas de objetos distribuídos é fornecer soluções para problemas complexos, ou seja, problemas que necessitam de arquiteturas, infra-estrutura e métodos bem definidos, integrando diversas tecnologias em ambientes heterogêneos com o objetivo de capturar e difundir informações de forma transparente para o usuário final e com eficiência. Data de recebimento: 11/12/2003. Data de aceitação: 30/01/2004. * Bacharel e m Ciência da C omputação pela USJT (1997), mestre em Engenharia da Computação e Sistemas Digitais pela EP-USP (2001), doutoranda nessa mesma área também pela EP-USP e professora nos cursos d e Ciência da C omputação e Sistemas de Informação da USJT. E-mail: prof.anapaula@usjt.br. 2. ARQUITETURA DE OBJETOS DISTRIBUÍDOS As arquiteturas de objetos distribuídos são baseadas no conceito de objetos distribuídos, ou seja, são técnicas e aplicações da orientação a objetos [3],

158 INTEGRAÇÃO SERRA Modelo de arquitetura CORBA utilizando a capacidade de comunicação provida pelo uso de redes de computadores. A característica básica da arquitetura de objetos distribuídos é o fato de que os objetos que a compõem encontram-se dispersos em máquinas diferentes, podendo estar em diferentes locais, rodando sobre diferentes plataformas e comunicando-se mediante a utilização de um componente responsável por gerenciar as chamadas remotas em uma arquitetura cliente servidor de múltiplas camadas [8]. Existem alguns modelos de arquiteturas de objetos distribuídos que têm facilidades de desenvolvimento de sistemas distribuídos orientados a objetos, e que podem auxiliar no desenvolvimento de sistemas de informação nas empresas. Alguns desses modelos de arquiteturas de objetos distribuídos são o Reference Model of Open Distributed Process (RM-ODP), o Common Object Request Broker Architecture (CORBA), o Distributed Component Object Model (DCOM)/.NET, o Java 2 Plataform Enterprise Edition (J2EE), o Distributed Computing Environment (DCE) e o System Object Model (SOM). Neste trabalho, será apenas apresentado o modelo detalhado da arquitetura CORBA. Para isso será apresentada a definição do modelo de arquitetura, os métodos de chamada e retorno de requisições, representado pelo diagrama de seqüência do Unified Modeling Language (UML) [3] e modelo de comunicação. 3. MODELO DE ARQUITETURA CORBA O Common Object Request Broker Architecture (CORBA) é um modelo de arquitetura de objetos distribuídos da Object Management Group (OMG, http://www.omg.com), uma organização sem fins lucrativos que visa a difundir a orientação a objetos para o desenvolvimento de sistemas distribuídos. O objetivo do CORBA é permitir interoperabilidade para objetos com independência de implementação, linguagem de programação, sistema operacional e hardware. O CORBA é um middleware aberto composto de objetos distribuídos, que define um padrão de desenvolvimento de aplicações distribuídas para ambientes heterogêneos, provendo a interoperabilidade entre os objetos de forma transparente, reusabilidade e portabilidade [1][2][8]. O CORBA foi criado em 1991 (versão 1.0), e atualmente encontra-se na versão 3.0. Entre as versões 1.0 e 3.0 vários serviços e características foram criados, como, por exemplo: repositório de interface, componentes portáveis, suporte a várias linguagens de programação (Smaltalk, C++, Java, entre outras), facilidades para desenvolvimento de aplicações médicas e de tempo real, suporte ao DCOM, integração com o J2EE e o extensible Markup Language (XML). O CORBA utiliza modelo de objetos remotos, e os objetos e serviços são especificados por meio de uma linguagem para a definição de interfaces chamada de CORBA IDL (Interface Definition Language). O CORBA IDL é uma linguagem declarativa padronizada pela OMG, independentemente de arquitetura, linguagem de programação e sistema operacional, que permite especificar as interfaces dos objetos distribuídos. A seguir é apresentado um exemplo da linguagem CORBA IDL [4][8][10]. module <nome> { // define um escopo de definições <declarações de tipos> <declarações de constantes> <d eclarações de exceções> interface <nome>[:herança]{// define uma interface <declarações de tipos> <declarações de constantes> <declarações de atributos> <d eclarações de exceções> <tipo><nome>(<parâmetros>) // define um método [r aises <exceções>] [context];... }... } 3.1 ARQUITETURA E ESTRUTURA DO CORBA A arquitetura geral na qual o padrão CORBA é gerado é a Object Management Architecture (OMA). A OMA é uma arquitetura também definida pela OMG, e é apresentada na Figura 1 [6] e explicada a seguir.

ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 159 Objetos de Aplicação Object Request Broker Objetos de Serviços Comuns Facilidades Comuns Figura 1. Visão geral da arquitetura OMA. Object Request Broker (ORB): É o componente central da OMA, é o responsável pela comunicação entre o cliente e o objeto distribuído independentemente da plataforma. Também garante a interoperabilidade, a busca e a ativação dos objetos e o controle das falhas de rede. Sua principal finalidade é fornecer mecanismos de requisições e respostas para qualquer objeto de forma transparente, ou seja, o ORB é responsável pela localização do objeto ao qual se destina a requisição, assim como o envio dos parâmetros da requisição no formato aceito pelo objeto. Também é função do ORB o retorno de parâmetros de saída da requisição para o cliente, caso exista [2][4][5][6][7][8]. Qualquer software que forneça as interfaces e os serviços especificados, como, por exemplo, a localização do objeto, a linguagem de programação utilizada para sua implementação e a ordenação de bytes da máquina na qual será executado o objeto, pode ser considerado um ORB [7]. Facilidades Comuns: São pacotes de serviços de objetos que facilitam o desenvolvimento de aplicações e que podem ser configurados para as necessidades de ambientes específicos, voltados para o nível de aplicação. As Facilidades Comuns são divididas em dois aspectos: as facilidades horizontais e as facilidades verticais [4][5][8]. Facilidades horizontais: consistem em serviços de alto nível que são independentes do domínio de aplicação, como interfaces de usuários, gerenciamento de informações, gerenciamento de sistemas e gerenciamento de tarefas [4][5][7][8]; Facilidades verticais: consistem em serviços de alto nível para especificação de aplicações de domínio, como e-commerce, sistemas bancários, sistemas de manufatura, sistemas de medicina, entre outros [4][5][7][8]. Objetos de Aplicação: São os componentes específicos que devem ser desenvolvidos para a aplicação [4][5]8]. Objetos de Serviços Comuns: São responsáveis por fornecer uma coleção de serviços para aplicação (interfaces e objetos), com funções básicas utilizadas em qualquer aplicação distribuída, como serviços de ciclo de vida, persistência, nomes de serviços, notificações de eventos, controle de concorrência, serviços de transação, serviços de pesquisa, segurança, atomicidade, consistência, entre outros [4][5][7][8]. Uma visão dos componentes da arquitetura OMA de acordo com o que foi descrito é apresentada na Figura 2 [6]. Além da utilização da arquitetura OMA, o CORBA tem uma arquitetura, apresentada na Figura 3 [6], e cada um dos seus componentes explicados a seguir. Uma visão detalhada do funcionamento dessa arquitetura é apresentada no item 3.2. IDL Stub: Fornecem mecanismos para os clientes enviarem requisições de forma transparente. São responsáveis pelo empacotamento da requisição e o desempacotamento da resposta. As IDL Stub são gerados Nomes Se rviç o Objetos da Aplicação Persistência Object Request Broker Eve ntos Ci clo d e Vi d a Facilidades Comuns Ver tic al Co mmo n Fa cili ti es Ap l icaçõ es d e D omí ni o Bancá rio E-Commerce Horizontal C o m mo n Fa c ili t ies Interface Gerenciam. Usuário Gerenciam. de Sistemas de Informações Tra nsações Query Objetos de Serviços Comuns Se gu ran ça Concorrência Figura 2. Visão dos componentes da arquitetura OMA.... Gerenciam. de Tarefas...

160 INTEGRAÇÃO SERRA Modelo de arquitetura CORBA IDL stub pela compilação da IDL e são interfaces estáticas [2][4]. Dynamic Invocation: Permite que as requisições sejam criadas e enviadas em tempo de execução para os objetos, interface dinâmica. As informações da chamada do objeto, os métodos e parâmetros necessários geralmente estão no repositório de interfaces [2][4]. IDL Skeleton: Oferece serviços para o recebimento da requisição. Identifica a requisição, desempacota os parâmetros, chama o objeto de implementação e a operação a ser carregada, executa a requisição, empacota o resultado e retorna a resposta ao cliente. As IDL Skeleton são interfaces estáticas, ou seja, a interface criada para requisição do método não pode ser alterada em tempo de execução, e já devem estar definidos a quantidade de parâmetros e seus tipos [2][4]. Dynamic Skeleton: Permite a manipulação dinâmica das requisições aos objetos. Os Dynamic Skeletons podem ser chamados por interfaces dinâmicas ou estáticas [2][4]. Object Adapter: Realiza a interação com o ORB Central e fornece acesso para serviços, incluindo a geração e interpretação de referências para objetos, invocação de métodos, segurança entre as interações, ativação e desativação de objetos e implementação, mapeamento de referência de objeto para implementação e para registro de implementação. Sendo diferente, o Object Adapter pode ser utilizado de acordo com o ORB utilizado [2][4][7]. CLIENTE Dynamic In vocation Repositório de Interface ORB Interface ORB Central IDL skeleton Figura 3. Estrutura geral do CORBA. OBJETO DISTRIBUÍDO DE IMPL EMENTAÇÃO Outros ORBs Object adapter Dynamic skeleton Repositório de Implementação Repositório de Interface: É um serviço que oferece objetos persistentes e que representam informações das IDLs em tempo de execução. As informações disponíveis no repositório são geralmente utilizadas pelo ORB para realizar invocações dinâmicas a objetos remotos. Usando a informação disponível no repositório é possível que um programa encontre um objeto remoto, mesmo não conhecendo sua interface, seus métodos, parâmetros e sua forma de ativação [4][7][8]. Repositório de Implementação: Contém informações que permitem que o ORB localize os objetos [2][4][7]. Outros ORB: São aplicações disponíveis para o cliente e os objetos distribuídos de implementação acessarem o ORB Central [2][4]. ORB Central: É o mais baixo nível na arquitetura ORB. Este nível suporta a representação básica dos objetos e os meios de comunicação entre objetos. A partir do CORBA 2.0 é fornecido o Basic Object Adapter (BOA), que é um ORB com diversas funcionalidades, sendo um adaptador de objeto padronizado pela OMG. E com o CORBA 2.2 já é possível a utilização do Portable Object Adapter (POA), que fornece padrão de interface para adaptador de objetos portáveis [2][4][7]. ORB Interface: Interface comum disponível para o cliente e a implementação acessarem o ORB Central. Como a maioria das funcionalidades do ORB, é fornecida pelos stubs, skeletons, invocações dinâmicas ou adaptadores de objetos; apenas operações comuns fazem parte da Interface ORB [4]. 3.2 CHAMADA E RETORNO DE REQUISIÇÕES NO CORBA O CORBA permite a integração com diversos tipos de sistema. Para isso, utiliza chamadas remotas a objetos. E a camada responsável pelas chamadas das requisições é o ORB. O cliente executa a chamada por meio da visão da interface da implementação do objeto, que pode ser uma invocação dinâmica ou estática para acessar o objeto. Invocação estática significa que todas as chamadas do cliente para implementação do objeto estão

ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 161 disponíveis no cliente, e para o cliente a chamada é idêntica a uma chamada de requisição local. Enquanto a invocação dinâmica significa que o cliente pode determinar em tempo de execução a interface de um objeto, descobrindo suas operações, tipos de parâmetros, preenchendo as informações necessárias para executar a requisição e realizar a invocação [4][8]. A invocação estática é realizada pela IDL stub, os stubs são gerados automaticamente para a linguagem desejada a partir da IDL, e transformados, geralmente, em bibliotecas que são ligadas ao código do cliente em tempo de compilação. A invocação dinâmica é realizada por meio do componente de invocação dinâmica com o auxílio de um repositório de interfaces [4][8]. A Figura 4-a apresenta uma visão geral de chamada e retorno de requisições estáticas, e a Figura 4-b apresenta uma visão geral de chamada e retorno de requisições dinâmicas no CORBA. Os procedimentos da chamada e do retorno de requisições estáticas e dinâmicas são os mesmos, diferindo apenas os componentes utilizados na arquitetura, e que já foram apresentados no item 3.1. Basicamente, a requisição é enviada por meio do ORB, em que o cliente executa a chamada da requisição por meio da interface da implementação do objeto. A IDL stub/dynamic Invocation empacota a requisição que é enviada por meio do ORB, que localiza o objeto e para isso pode utilizar o auxílio de serviços do Object Adapter e do repositório de implementação. A resposta da requisição passa pelo mesmo processo da chamada da requisição. 3.3 MODELOS DE COMUNICAÇÃO CORBA Visando a garantir a interoperabilidade entre objetos pertencentes a diferentes implementações de ORBs, o CORBA suporta os seguintes protocolos de comunicação [1][7]: Protocolo General Inter-ORB Protocol (GIOP): Especifica um conjunto de formatos das mensagens e dados para a comunicação entre ORBs; Protocolo Internet Inter-ORB Protocol (IIIOP): Especifica como mensagens GIOP operam em TCP/IP; Protocolo Environment-Specific Inter-ORB Protocols (ESIOP): Especifica a interoperabilidade do ORB com outros ambientes, como, por exemplo, DCE e DCOM. E antes da versão 2.0 do CORBA era difícil garantir a interoperabilidade entre objetos Figura 4-a. Visão geral de chamada e resp osta de requisições estáticas no CORBA.

162 INTEGRAÇÃO SERRA Modelo de arquitetura CORBA Figura 4-b. Visão geral de chamada e retorno de respostas dinâmicas no CORBA. pertencentes a diferentes implementações de ORBs, pois somente havia uma padronização no nível de interface, ficando em aberto aos desenvolvedores a parte de implementação. 4. CONCLUSÕES O CORBA é um modelo de arquitetura não comercial, ou seja, não pertence a uma única empresa; com isso, é um padrão que pode ser utilizado em diferentes plataformas. O CORBA fornece as abstrações e serviços necessários ao desenvolvimento de aplicações distribuídas e portáveis, sem a necessidade de preocupação com detalhes de baixo nível, como, por exemplo: facilidades para controle dos sistemas de informação distribuídos, como gerenciador de tarefas e interfaces, e componentes para aplicações específicas, como área médica, sistemas de tempo real e e-commerce; componentes que podem ser utilizados em qualquer tipo de sistemas de informação, como controle de transações, segurança, persistência, entre outros; independência de linguagens de programação e de sistemas operacionais, o que propicia uma base sólida tanto para a integração de sistemas legados quanto para o desenvolvimento de novas aplicações; flexibilidade de criação de componentes que podem ser desenvolvidos e integrados ao CORBA. A aplicação do modelo de arquitetura CORBA pode ser utilizada em qualquer sistema de informação distribuído, ou que necessite da comunicação com outro sistema de informação, não importando a plataforma e a linguagem de programação, pois por meio do CORBA IDL e do ORB podem-se realizar uma integração transparente e a execução de métodos em componentes remotamente. Com certeza, o CORBA continuará ganhando espaço no cenário da computação distribuída devido a quatro fatores: flexibilidade, independência de linguagem, utilização da orientação a objetos e um amplo conjunto de capacidades para necessidades de distribuição. Referências bibliográficas 1 BALEN, H. Distributed object architectures with CORBA. Cambridg e University Press/Sigs, 2000.

ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 163 2 BLAIR, G.; COULSON, G. & DAVIES, N. Standards and platforms for open distributed processing. Electronics & Communication Engineering Journal, junho de 1996, pp. 123-33. 3 BOOCH, G.; JACOBSON, I. & RUMBAUGH, J. UML Guia do usuário. Trad. de F. Freitas. Rio de Janeiro: Campus, 2000, 472 p. 4 MAINETTI, S. Objetos distribuídos. Visionnaire, 1997, 14 p. 5 OBJECT MANAGEMENT GROUP INC. Object management architecture guide, 1995, 3ª ed. 6 ORFALI, R. & HARKEY, D. Client/server programming with Java and CORBA. John Wiley & Sons, 1998, 2ª ed., 1072 p. 7 RICCIONI, P.R. Introdução a objetos distribuídos com CORBA. Florianópolis: Visual Books, 2000, 104 p. 8 TANEBAUM, A.S. & STEEN, M. Distributed systems. Principles and paradigms. Prentice Hall, 2002, 803 p. 9 TELEFÓNICA. A soc iedade da informação no Brasil. São Paulo: Takano, 2002, 1ª ed., 241 p. 10 TOMPSON, D. & WATKINS, D. Comparisons between CORBA and DCOM: Architectures for distributed computing. Austrália: IEEE, 1998, pp. 278-83.

164 INTEGRAÇÃO SERRA Modelo de arquitetura CORBA