Desenvolvimento em CORBA. Novos Desenvolvimentos em CORBA

Transcrição

1 Desenvolvimento em CORBA Onde utilizar CORBA? CORBA é uma arquitetura para sistemas distribuídos, tipicamente utilizada em: novos desenvolvimentos; integração de produtos e sistemas legados ; hooks e gateways de interoperabilidade. (c) FEEC/UNICAMP e IC/UNICAMP 132 Novos Desenvolvimentos em CORBA A utilização de CORBA em novos desenvolvimentos se justifica devido a: ampla aceitação por parte da indústria; maturidade dos produtos CORBA disponíveis no mercado; neutralidade em termos de plataformas e linguagens de programação; simplicidade de uso quando comparado a outras tecnologias (ex: DCOM e DCE); integração natural com tecnologias relacionadas à Internet (applets, browsers, etc.). (c) FEEC/UNICAMP e IC/UNICAMP 133

2 Integração via CORBA CORBA é uma tecnologia adequada para a integração de sistemas legados (exemplo: controle de estoques desenvolvido em COBOL para IBM OS/390 utilizando DB2). Nestes casos, a interação com o sistema legado pode se dar através de um wrapper dividido em duas partes: 1. parte responsável pela interação com um ORB, por exemplo, através de stub gerado por compilador IDL; 2. parte responsável pela interação com o sistema legado através de, por exemplo, interfaces de programação (APIs). (c) FEEC/UNICAMP e IC/UNICAMP 134 Integração via CORBA Exemplo: Sistema Legado #1 (COBOL / OS/390) Sistema Legado #2 (C++ / UNIX) Sistema Legado #3 (V.Basic / Windows) wrapper #1 wrapper #2 wrapper #3 IDL > COBOL IDL > C++ COM-CORBA bridge ORB #1 IIOP IIOP ORB #2 ORB #3 (c) FEEC/UNICAMP e IC/UNICAMP 135

3 Hooks CORBA de Interoperabilidade Produto Hook CORBA de Interoperabilidade IDL exportada pelo produto Extensão ao Produto ORB interno ao produto IIOP ORB Comercial Hooks CORBA de interoperabilidade permitem adicionar funcionalidades externas a produtos. Exemplos: Plataforma Jambala para telefonia celular (Ericsson) Sistema de gerência de redes OpenView (HP) (c) FEEC/UNICAMP e IC/UNICAMP 136 Gateways de Interoperabilidade Gateways permitem sistemas baseados em CORBA interoperarem com sistemas baseados em outras arquiteturas e protocolos. Exemplo: Agente SNMP SNMP Gateway IDL - SNMP ORB IIOP Gerente CORBA ORB Comercial Domínio de Gerência SNMP IDL exportada pelo gateway Domínio de Gerência CORBA (c) FEEC/UNICAMP e IC/UNICAMP 137

4 ORBIX Orbix, produto da Iona Technologies, é um dos produtos CORBA mais utilizados e mais completos. Orbix possui compiladores IDL para várias linguagens de programação, bem como ORBs para uma grande variedade de plataformas. Por exemplo, é possível desenvolver um servidor CORBA em COBOL e executá-lo num mainframe IBM OS/390. Orbix possui ainda vários utilitários e aplicativos descritos na sequência. (c) FEEC/UNICAMP e IC/UNICAMP 138 ORBIX: Disponibilidade Orbix possui versões para desenvolvimento em C++ para as seguintes plataformas: Microsoft Windows NT; Sun Solaris; HP-UX; Silicon Graphics IRIX; IBM AIX; IBM OS/390 Mainframe; Digital Unix; Digital OpenVMS. (c) FEEC/UNICAMP e IC/UNICAMP 139

5 ORBIX: Compilador IDL compilador IDL stubs, skeletons, server template arquivo IDL parser IDL árvore de parsing gerador de código Code Generation Toolkit utilitários aplicação-exemplo conversão IDL - HTML etc. (c) FEEC/UNICAMP e IC/UNICAMP 140 ORBIX: ORB No Orbix o Object Request Broker (ORB) consiste de dois componentes: 1. Uma interface de programação (API) que provê funções relativas ao ORB para clientes e servidores tais como binding, DII (cliente); iniciação de servidores, DSI (servidor); 2. Um daemon (orbixd) que executa em cada máquina da rede e gerencia o repositório de implementação e ativação de servidores. (c) FEEC/UNICAMP e IC/UNICAMP 141

6 ORBIX: ORB busca de servidor ORBIX daemon (orbixd) Rep. Impl. instancia servidor código da aplicação (cliente) API código da aplicação (servidor) API código do stub (gerado pelo compilador IDL) ORB (lib) requisição IIOP ORB (lib) código do skeleton (gerado pelo compilador IDL) (c) FEEC/UNICAMP e IC/UNICAMP 142 ORBIX: ORB Orbix ORB possui as seguintes características básicas: suporte para DII (Dynamic Invocation Interface); suporte para BOA e POA (Basic/Portable Object Adapter); suporte para DSI (Dynamic Skeleton Interface). Orbix ORB provê ainda uma interface para operações de manipulação de typos (Any, NVList,...), disponibilização de servidores (impl_is_redy), busca de serviços disponíveis (nomes, eventos,...), dentre muitas outras. (c) FEEC/UNICAMP e IC/UNICAMP 143

7 ORBIX: Extensões ao ORB API multithreaded: permite a construção de servidores multithreaded com diferentes políticas de criação de threads, por exemplo, criar uma thread por objeto, uma thread por requisição requisição, ou um pool de threads para processar as requisições; Filtros: permite a intercepção de requisições e respostas para a implementação de funções específicas (por exemplo, criptografia); Carregadores: permite a implementação de objetos persistentes; Smart Proxies: permite especializar o comportamento de um proxy (representação local de um objeto remoto). (c) FEEC/UNICAMP e IC/UNICAMP 144 ORBIX: Repositórios Orbix dispõe de repositórios de interface e de implementação com a seguinte arquitetura: repositório registros sistema de arquivos nativo da máquina utilitários de manutenção e gerência putit catit lstit rmit... (c) FEEC/UNICAMP e IC/UNICAMP 145

8 ORBIX: Componentes Adicionais A IONA Technologies disponibiliza uma série de produtos adicionais para o Orbix: COMet: integração COM/CORBA; OrbixNames: serviço de nomes; Orbix Wonderwall: firewall; OrbixOTS: transações distribuídas; OrbixTrader: trader OrbixWeb: ORB implementado 100% em Java. (c) FEEC/UNICAMP e IC/UNICAMP 146 ORBIX: COMet COMet permite que servidores CORBA se apresentem a clientes como objetos COM (Component Object Model - padrão Microsoft). cliente COM Bridge COM IIOP servidor (COMet) CORBA provê mapeamento bidirecional entre MIDL e OMG IDL repositório de tipos (COM) repositório de interfaces (CORBA) OBS: MIDL (Microsoft IDL) define tipos COM (c) FEEC/UNICAMP e IC/UNICAMP 147

9 ORBIX: OrbixNames Orbix implementa um serviço de nomes persistente compatível com o padrão OMG (OrbixNames). Este padrão especifica interfaces IDL para: criar contextos para definições de nomes; associar (bind) um nome a um objeto (usualmente um servant); pesquisar um nome (e obter o objeto associado). interfaces IDL do serviço servant CORBA repositório de nomes servidor OrbixNames (c) FEEC/UNICAMP e IC/UNICAMP 148 ORBIX: Wonderwall Wonderwall é um firewall capaz de filtrar, controlar e registrar o fluxo de mensagens IIOP inter-organizacional. mensagem IIOP bastion host rede interna Internet Intranet Orbix Wonderwall objetos CORBA (c) FEEC/UNICAMP e IC/UNICAMP 149

10 ORBIX: OrbixOTS OrbixOTS implementa o serviço de transações do OMG (Object Transaction Service - OTS) baseado no protocolo 2-phase commit. interfaces IDL do serviço servidor OrbixOTS servant CORBA interface XA (X/Open) base de dados (Oracle, Sybase, etc.) permite a integração com produtos que implementam esta interface (c) FEEC/UNICAMP e IC/UNICAMP 150 ORBIX: Trader Trader, conceito introduzido no modelo ODP, foi padronizado pelo OMG. Trader é um serviço de nomes mais sofisticado que permite clientes encontrar servidores que melhor atendam suas necessidades. Cenário típico de utilização do trader é dado abaixo. cliente CORBA OrbixTrader servidor CORBA ORB 1. exporta capacidades do servidor (desempenho, custo, etc.) 2. importa requisitos (desempenho mínimo, custo máximo, etc.) 3. retorna IOR do servidor 4. interage com o servidor (provavelmente via DII) (c) FEEC/UNICAMP e IC/UNICAMP 151

11 ORBIX: OrbixWeb OrbixWeb é um ORB 100% escrito em Java que: permite plena integração com a WWW: um objeto CORBA pode estar contido num applet executando na máquina virtual Java do navegador; o próprio ORB pode ser descarregado como applet. possui plana interoperabilidade com qualquer produto Orbix; mantém o mesmo formato dos repositórios de interface e implementação; possui daemon (orbixdj) capaz de instanciar tanto servidores escritos em Java como em outras linguagens de programação. (c) FEEC/UNICAMP e IC/UNICAMP 152 VisiBroker VisiBroker tem sua origem no ORBeline, produto da PostModern que em 1996 fundiu-se com a Visigenic, mudando o nome do produto para VisiBroker. A Visigenic foi adquirida pela Imprise (ex-borland) que manteve o nome do produto, hoje na versão 4. VisiBroker foi o primeiro ORB a ter uma versão totalmente escrita em Java. (c) FEEC/UNICAMP e IC/UNICAMP 153

12 VisiBroker: Disponibilidade VisiBroker possui versões para desenvolvimento em C++ e Java para as seguintes plataformas: Microsoft Windows 95/98/NT; Sun Solaris; Redhat Linux; HP-UX; IBM AIX; IBM OS/390 Mainframe. (c) FEEC/UNICAMP e IC/UNICAMP 154 VisiBroker: Características VisiBroker possui as seguintes características básicas: repositórios de interface e implementação; suporte para DII (Dynamic Invocation Interface); suporte para BOA e POA (Basic/Portable Object Adapter); suporte para DSI (Dynamic Skeleton Interface); suporte a multithreading (vários modelos de threading); suporte a Object-by-Value (OBV); Filtros (Interceptors). (c) FEEC/UNICAMP e IC/UNICAMP 155

13 VisiBroker X Orbix VisiBroker é muito similar ao Orbix, sendo talvez o seu maior concorrente. Algumas diferenças: possui dois daemons: SmartAgent e OAD (Object Activation Daemon): SmartAgent: provê serviços de nome e diretório que permite localizar OADs. A localização pode levar em conta balanceamento de carga e tolerância a falhas; OAD: utilizado para instanciar servidores (similar ao orbixd). serviço de nomes e eventos (OMG) incorporados. (c) FEEC/UNICAMP e IC/UNICAMP 156 VisiBroker: SmartAgent & OAD Serviço Distribuído de Nomes + Diretório SmartAgent SmartAgent 1. consulta 2. encontra servidor SmartAgent Algoritmos de Bal. de carga Tol. a Falhas 3. retorna ref. OAD cliente 4. bind 5. acessa impl. OAD 6. inst. servidor OAD Rep. Impl. Rep. Impl. (c) FEEC/UNICAMP e IC/UNICAMP 157

14 VisiBroker: Componentes Adicionais A Imprise oferece os seguintes componentes adicionais para o VisiBroker: VisiBridge: bridge CORBA-COM similar ao COMet do Orbix; VisiBroker GateKeeper: firewall similar ao Wonderwall do Orbix; VisiBroker ITS: implementação do serviço de transações do OMG similar ao OrbixOTS; adicionalmente, os seguintes CORBAservices são oferecidos pela Prism Technologies para o VisiBroker: Trading, Notification, LifeCycle, Property, Collection, Concurrency, Relationship, e Time Services. (c) FEEC/UNICAMP e IC/UNICAMP 158 Java 2 ORB Java 2 (JDK 1.2.x) possui um ORB interno implementado como pacote (bibliotecas) java. Acompanha este ORB: compilador IDL para java: idltojava; servidor de nomes transiente (não persistente) padrão OMG: tnameserv. Java 2 ORB possui as seguintes características básicas: suporte para DII (Dynamic Invocation Interface); suporte para POA (Portable Object Adapter); suporte para DSI (Dynamic Skeleton Interface). (c) FEEC/UNICAMP e IC/UNICAMP 159

15 Java 2 ORB: Implementação Java 2 ORB não possui daemon de ativação como Orbix e VisiBroker, bem como repositórios de interface e implementação. Isto implica que servidores devem ser instanciados por mecanismo externo ao ORB (ex: manualmente). O ORB é disponibilizado como pacote java, estanto integralmente incorporado nos clientes e servidores. cliente pacote org.omg.corba servidor ORB IIOP ORB (c) FEEC/UNICAMP e IC/UNICAMP 160 Microsoft DCOM DCOM (Distributed Component Object Model) é uma generalização da tecnologia COM (ex-ole) desenvolvida pela Microsoft para o mundo Windows. Portanto, OLE/COM/DCOM são soluções fechadas. COM permite a comunicação entre aplicativos executando no mesmo processador. Portanto, COM um mecanismo de comunicação inter-processos (IPC). DCOM estende COM permitindo a comunicação entre aplicativos executando em diferentes processadores. Portanto, DCOM é um middleware. (c) FEEC/UNICAMP e IC/UNICAMP 161

16 Microsoft DCOM servidor COM servidor DCOM IPC RPC rede cliente COM cliente e servidor em diferentes (processos) mas no mesmo processador cliente DCOM cliente e servidor em diferentes processadores (c) FEEC/UNICAMP e IC/UNICAMP 162 Microsoft DCOM COM é neutro em termos de linguagem de programação. Por exemplo, um cliente escrito em Visual Basic pode interagir com um servidor escrito em C++. Para permitir esta neutralidade uma linguagem de definição de interfaces foi definida pela Microsoft: MIDL (Microsoft Interface Definition Language). DCOM procura minimizar as diferenças em relação ao COM (transparência de distribuição), escondendo do desenvolvedor o fato de clientes e servidores estarem em processadores distintos. DCOM utiliza um mecanismo de RPC (derivado do DCE!) para suporte à comunicação cliente/servidor. (c) FEEC/UNICAMP e IC/UNICAMP 163

17 DCOM: Arquitetura cliente DCOM proxy servidor DCOM stub cria instância (de servidor) instancia SCM segurança DCE RPC protocolos de rede (TCP/IP) hardware SCM segurança DCE RPC protocolos de rede (TCP/IP) hardware SCM: Service Control Manager (parte do Windows) rede (c) FEEC/UNICAMP e IC/UNICAMP 164 DCOM: Objetos COM/DCOM classe (coclass) interface Objetos COM/DCOM derivam de uma classe base (coclass), definem uma interface com detrminado número de métodos, e podem ser agregados numa biblioteca (lib). lib classe (coclass) classe (coclass) interface interface O objeto, sua interface e a lib a qual pertence são individidual- e globalmente identificados por um UUID (ou GUID) (Universally/Globally Unique IDentifier), uma sequência de 128 bits gerada por um aplicativo denominado guidgen. guidgen leva em conta a data, hora, host ID, etc. para gerar um GUID. (c) FEEC/UNICAMP e IC/UNICAMP 165

18 DCOM: MIDL import "oaidl.idl"; import "ocidl.idl"; [object, uuid(3c6e c-11d4-96b bdbda), dual helpstring("iaccountcomobject Interface"), pointer_default(unique)] interface IAccountComObject : IDispatch { HRESULT deposit([in] unsigned long amount); HRESULT withdraw([in] unsigned long amount); HRESULT balance([out, retval] long *amount);}; [uuid(3c6e c-11d4-96b bdbda), version(1.0), helpstring("account 1.0 Type Library")] library ACCOUNTLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [uuid(3c6e c-11d4-96b bdbda), helpstring("accountcomobject Class")] coclass AccountComObject { [default] interface IAccountComObject; }; }; (c) FEEC/UNICAMP e IC/UNICAMP 166 DCOM: Desenvolvimento Desenvolver aplicações distribuídas em DCOM exige: experiência com o mundo Windows, principalmente com a tecnologia COM; um ambiente de desenvolvimento que contenha gerador de GUID (guidgen), compilador MIDL (midl), compilador da linguagem alvo, etc. Os ambientes Microsoft Visual C++, Basic e J++ contém estes aplicativos. Nos ambientes Microsoft, clientes e servidores COM/DCOM são desenvolvidos a partir de um wizard (ATL COM AppWizard). (c) FEEC/UNICAMP e IC/UNICAMP 167

19 DCOM: Servidores Servidores DCOM podem ser instanciados de duas maneiras: por demanda, quando uma requisição para um objeto for gerada por um cliente; de forma persistente, como um serviço do sistema operacional (Windows-NT apenas); NOTA: o Register do Windows é empregado para mapear classes de objetos e suas interfaces (através de seus GUIDs) em servidores (programas executáveis). Funciona, portanto, como o repositório de implementação do CORBA. NOTA: o SCM do Windows funciona para o DCOM como os daemons de ativação do CORBA (orbixd, OAD). (c) FEEC/UNICAMP e IC/UNICAMP 168 A favor do CORBA: CORBA x DCOM CORBA é uma arquitetura aberta, independente de plataforma ou fornecedor; CORBA é mais aceito por fornecedores de software; desenvolvimento em CORBA é mais simples que em DCOM; CORBA se integra melhor com Java/Internet que DCOM; CORBA é um middleware mais completo que DCOM; CORBA permite late-binding via DII; mercado de produtos CORBA bem superior ao mercado de produtos DCOM; CORBA também opera em ambientes Windows. (c) FEEC/UNICAMP e IC/UNICAMP 169

20 CORBA x DCOM A favor do DCOM: força de mercado da Microsoft; perfeitamente integrado ao mundo Windows ; estende COM, uma tecnologia bem conhecida pelos desenvolvedores para Windows; integrado aos ambientes de desenvolvimento Microsoft (Visual xxx); utiliza elementos já disponíveis no Windows (Register, SCM, segurança, etc.). (c) FEEC/UNICAMP e IC/UNICAMP 170