1.264 Lição 16 Legado Middleware
O que é o legado middleware? Cliente (interface do usuário, aplicativo local). Cliente (interface do usuário, aplicativo local). Como conectamos clientes e servidores? MIDDLEWARE Rede Pré-Web, mas Pós-Internet!! Servidor (base de dados, aplicativo, etc.) Servidor (base de dados, aplicativo, etc.)
Por que middleware? Desenvolvimento da Internet Muitos usuários conectados nas redes de área ampla, com alta largura de banda. PCs potentes e baratos Muito mais usuários nas empresas e na Internet Rede e computação liderando os negócios na Net Compras, transações, cadeia de suprimentos, projetos colaborativos, gerenciamento de projetos,... Milhões de servidores pré-web conectados larguras de banda elevadas Aplicativos de pré-web com trilhões de transações distribuídas O tradicional projeto de cliente-servidor não é escalonável. Cliente-servidor significa um servidor Excelente para aplicativo departamental numa rede de área local (LAN) Necessidade de múltiplos servidores para manusear os aplicativos em nosso mundo novo Necessidade do middleware cliente-servidor
Por que middleware? (cont.) Os aplicativos não estão na escala correta O Excel aumentou de 4MB para 32MB de memória RAM, de 1990 a 2000. O Lotus 1-2-3 aumentou de 0,5MB para 11MB de 1982 a 1997. Idem para o Word, PowerPoint, Access. E continua crescendo... Muitos compartilham recursos comuns: gráficos, tabelas, formatação, mail merge, etc. Os componentes permitem códigos compartilhados através dos aplicativos (aplicativo de middleware) A falta e as altas despesas dos desenvolvedores de software As deseconomias do desenvolvimento de software, à medida que aumenta o tamanho do projeto O legado do middleware também não se situa numa escala muito correta. Os mesmos conceitos de middleware utilizados para compartilhar códigos nos aplicativos e através da rede entre clientes e servidores: Os aplicativos devem se comunicar com outros aplicativos que fornecem alguns recursos compartilhados necessários, tanto no mesmo computador quanto em um diferente.
Por que não o SQL? O SQL gerencia apenas os dados, e não os processos. OK para o retorno da lista de portadores em um estado. Não está OK para o retorno de rotas otimizadas de caminhões para fornecimentos Desempenho do SQL através das redes é fraco As seqüências das declarações de SQL e retornos de consulta têm alto atraso. Mais rapidez para ter os procedimentos armazenados no servidor da base de dados solicitado por uma chamada de função, executar como um grupo e retornar como um único conjunto de resultados. Executar o procedimento Cliente Retornar os resultados Inserir, deletar Cliente Atualizar Servidor Servidor Procedimento armazenado DB DB
Objetos distribuídos Como você encontra todas as partes de um aplicativo, quando não puder ou não tiver todos em seu PC ou estação de trabalho? Objetos distribuídos = componentes Objeto: parte do aplicativo dentro de um único aplicativo (dados, métodos) Componente: uma parte do aplicativo que pode interoperar através dos sistemas de operação, redes, linguagens, aplicativos, ferramentas, hardware. Diversos padrões competitivos: Chamada de procedimento remoto (RPC): síncrono Arquitetura do Agente de Requisição para Objeto Comum (CORBA): consórcio ActiveX (COM, DCOM, OLE): Microsoft Linguagem de marcação extensível (XML): consórcio Protocolo do Aplicativo de um Objeto Simples (SOAP): baseado no XML Middleware orientado por mensagem (MOM); assíncrono XML, BizTalk (a Microsoft prefere simplesmente o MOM versus RPC) Monitores de processamento de transações (monitores TP) Proprietário, para bases de dados heterogêneas de alto volume
Middleware de chamada de procedimento remoto Dois padrões RPC competitivos do legado Arquitetura de Agente de Requisição para Objeto Comum (CORBA) ActiveX/COM/DCOM Os componentes vivem em barramentos de objetos distribuídos (ActiveX/COM ou CORBA) Os barramentos de objetos proporcionam suporte ao sistema: os serviços que os componentes herdam no tempo de construção ou de funcionamento para colaborar com outros componentes. Os componentes são arquitetados para trabalharem com outros componentes a partir do início.
Componentes (legado e WSDL) Exigências básicas: Comercializável Não como um aplicativo completo Utilizável em combinações imprevisíveis (igual à base de dados!) Interface bem especificada Interoperável através de linguagens, redes, sistemas de operação,... Recursos desejáveis: Segurança: proteção própria, autenticar-se para os clientes, registros de comandos Licenciamento, interpretação, metadados: providenciar dados sobre si mesmo Notificação de eventos: notificar as partes interessadas quando algo ocorre Configuração e gerenciamento de propriedade, criação de scripts Suporte para caixa de ferramentas abertas
COM Modelo de componentes com uso mais amplo Arquitetura bottom-up: sem arquitetura total, os recursos adicionados de versão para versão como viáveis. Modelo de objeto fundamental no qual o ActiveX repousa. O COM permite que um objeto exponha sua funcionalidade para outros componentes e aplicativos principais. O COM define tanto como o objeto expõe a si mesmo e como esta exposição trabalha através dos processos e através das redes. O COM também define o ciclo de vida útil de seu objeto. Exemplos: Os controles do ActiveX podem falar entre si e com os formulários do Visual Basic. Todos atendem ao padrão da interface do ActiveX Os controles personalizados são normalmente construídos para os padrões do ActiveX. Os programas Visio, Quicken, Oracle, etc., proporcionam controles
Conceitos de COM Interfaces: Mecanismo por meio do qual um objeto expõe sua funcionalidade. Tabela de funções (indicadores para) implementadas pelo objeto. Substituído por UDDI, WSDL e XML no middleware da Internet Discovery [lunknown (interface desconhecida)]: Interface básica na qual todas as demais se baseiam. Interface de Query: Método usado para consultar um objeto de uma determinada interface. Também retorna (indicador para) a função ou notifica o cliente de que ela não existe. Contagem de referência: Técnica pela qual um objeto (ou estritamente, uma interface) decide quando ele não está sendo mais utilizado, estando portanto livre para remover a si mesmo. Conta o número de referências dos clientes; libera quando for 0. O J2EE e o ASP.NET manuseiam este no middleware da Internet. Empacotamento (marshalling): Mecanismo que habilita os objetos a serem usados através de encadeamento, processo, e limites de redes, permitindo independência de localização. O COM fornece um código para compactar os parâmetros dos métodos em um formato que pode ser movido através de processos (bem como através de rede para processos rodando em outras máquinas) e para descompactar estes parâmetros na outra extremidade. SOAP (SML) efetua isto através da Internet. Agregação: Permite que um objeto faça uso de outro. Não implementada na Internet
Interfaces COM As interfaces COM possuem uma identificação única globalizada (GUID) Número de 128 bits, gerado por utilitário para prevenir colisões. O COM é uma linguagem independente Nenhuma noção de como o componente subjacente (objeto) é implementado Apenas a interface e o padrão de empacotamento do COM é exposto. Esta é a chave para reutilização. Se quaisquer fatores internos forem expostos, eles podem e irão criar problemas se eles forem alterados. Transparência local/remota. O objeto COM pode estar: Dentro do mesmo processo (.EXE) Na mesma máquina Na máquina remota Use o registro MS para localizar componentes na rede Deve instalar potencialmente uma entrada para todo componente em cada computador: escalonabilidade, segurança, confiabilidade, problemas de desempenho. O COM acha-se essencialmente num beco sem saída, ainda que em amplo uso.
Aplicativo com base em componente ActiveX/COM Interface ActiveX Fabricante do Componente ActiveX Construir Interface ActiveX Comprar Componente Químico ActiveX Entrada do Pedido do componente ActiveX Comprar, configurar Conexão ADO Produtos Químicos DB Oracle Conexão ADO Pedido DB Sybase Bases de dados nos servidores na rede empresarial
Objetos de Dados Activex DB server Web server Browser
Objetos de Dados Activex (cont.) Os componentes podem estar todos em uma máquina, ou cada componente pode estar em uma máquina diferente. Arquitetura de um, dois ou três níveis. O catálogo químico e os componentes de entrada de pedidos podem ter interface do usuário, se estiverem no PC do cliente. Alternadamente, eles podem ser componentes de servidores, e o vendedor destes componentes fornecerá componentes UI separados para serem incluídos no PC do cliente. Lembre-se dos problemas de desempenho do SQL clienteservidor. Os formulários e navegação podem ser configurados. As bases de dados e os componentes devem estar em rede corporativa Isto não se aplica pela Internet: desempenho, segurança, protocolo
CORBA O CORBA é um middleware padrão aberto que estabelece relacionamentos remotos entre objetos. O cliente pode solicitar o método de modo transparente no objeto do servidor em rede. O objeto parece ser local para o aplicativo do cliente. O Agente de Solicitação do Objeto (ORB) é o objeto-chave do CORBA: Intercepta chamada do cliente para o servidor É responsável por localizar um objeto que pode implementar a solicitação. Passa à mesma os parâmetros Chama o seu método Retorna os resultados ao cliente O cliente não está ciente de onde o objeto se localiza, sua linguagem de programação, do sistema de operação. O CORBA fornece interoperabilidade em ambientes heterogêneos. O COM é essencialmente apenas Microsoft, embora existam extensões.
CORBA Definido pelo Grupo de Gerenciamento de Objetos (OMG), fundado em 1989 como um consórcio de vendedores de objetos (atualmente com 800 membros). O website é www.omg.org A versão atual é CORBA 2.x no campo; a espec do CORBA 3.0 está fora de uso. Agente de Solicitação de Objeto (ORB) Permite aos clientes recorrer aos métodos em objetos remotos. Se o objeto remoto tiver interface de componentes, o objeto chamado vincula-se a uma rotina independente para chamar seus métodos. Do contrário, consulte o Repositório da Interface para descobrir os métodos. Comunicação entre ORBs via rede de transmissão backbone tcp/ip (da internet). O barramento de objeto tem serviços de objetos Normas sobre como os objetos são criados, armazenados, definidos e nomeados no barramento Em processos: serviço de eventos, transações, relacionamentos, consultas, licenciamento... Exemplo: reserva de cargas aéreas Mostra as empresas transportadoras, os vôos, disponibilidade de espaço, book space, pagamento,
ORB CORBA Cliente Implementação do Objeto Chamada dinâmica Rotina independente de IDL do Cliente Interface ORB Esqueletos estáticos Chamada de esqueletos dinâmicos Adaptador de objeto Núcleo do Agente de Solicitação de Objeto Repositório de interface Repositório de Implementação
Componentes da ORB do cliente Rotinas independentes IDL do Cliente (vinculação estática) As rotinas independentes chamam os serviços atualmente residentes em servidores No entanto, pela perspectiva do cliente, o objeto do servidor parece ser local A rotina independente atua como um procurador (proxy) para o objeto distante Os arquivos de cabeçalho (nomes e argumentos das funções) para chamar os métodos localmente a partir das linguagens de programação são disponibilizados localmente. A rotina independente executa as mensagens (empacotamento): codifica e decodifica os parâmetros em mensagens para o servidor e do mesmo. Interface de Chamada Dinâmica: (Vinculação Dinâmica) A interface padrão para os metadados do Repositório da Interface que define todos os objetos dos servidores. Permite a pesquisa, a listagem/geração de parâmetros, a emissão de solicitação remota e o retorno dos resultados Repositório de Interface Contém informações em classes suportadas (componentes).
Componentes da ORB do servidor Rotinas independentes ou esqueletos IDL do servidor: O mesmo das rotinas independentes IDL do cliente O objeto do servidor não está realmente sendo chamado localmente no cliente, porém seu esqueleto faz com que pareça deste modo. A Interface do esqueleto dinâmico: É a mesma da interface de chamada dinâmica no cliente A mensagem, processada de modo diferente, está em formato mais genérico. Adaptador do objeto (gerente): Não é necessário no cliente, o qual possui menos objetos ou processos Aceita solicitações de objetos do servidor, atribui identificações de objetos, registra classes suportadas em servidor (bem diferente do ActiveX) Repositório de implementação Similar ao repositório da Interface do cliente, que fornece informações em tempo de execução sobre as classes suportadas, os objetos são instanciados no servidor.
Linguagem de Definição de Interface (IDL) do Corba As interfaces para os objetos são os códigos Definidas usando-se a Linguagem de Definição de Interface (IDL) A IDL é compilada em todas as partes nas páginas anteriores Similar às funções da tabela do COM dos (indicadores para). O Java agora gera a IDL automaticamente C++ Java Cobo C++ Java Cobo IDL IDL IDL IDL IDL IDL Cliente Servidor ORB
Comunicação Inter-ORB O IIOP é o Protocolo Inter-ORB da Internet
Problemas do ORB Os ORBs comerciais continuam um tanto lentos e ineficientes. Sem balanceamento de carga, tolerância de falhas, escalonando milhões de transações A descoberta dos objetos através dos ORBs em larga escala não éclara: Diretórios de difusão, base de dados central,...? O código do servidor não é muito portátil, embora o código do cliente seja Atraso nas especificações no lado do servidor Os eventos, transações, etc., ainda não estão amplamente disponíveis. Problemas de interoperabilidade entre os ORBs competitivos Visigenic (Inprise), Iona são implementações de liderança. O CORBA é o projeto top-down (estruturado de cima para baixo): arquitetura boa, serviços limitados. O ActiveX/COM é bottom-up (estruturado de baixo para cima): arquitetura deficiente, grande volume de serviços.
Aplicativo baseado nos componentes CORBA ORB Comprar ORB IIOPP Componente de aplicativo de produtos químicos Componente de aplicativo fabricado ORB Construir IIOPP Componente de aplicativo de entrada de pedidos Comprar, configurar IIOPP ORB DB de Química ORB IIOPP DB de Pedido Bases de dados nos servidores em rede empresarial Oracle Sybase
Aplicativo CORBA, continuação Os componentes podem estar todos em uma máquina, ou cada componente pode estar em uma máquina diferente. Arquitetura de uma, duas, ou três vinculações. Mesmas opções, com flexibilidade ainda mais fácil do que o COM/ActiveX. Um ORB por computador. Se alguns componentes estiverem no mesmo servidor, haverá apenas um ORB naquele servidor. As bases de dados e os componentes devem estar em rede corporativa. Isto não funcionará na Internet: desempenho, segurança, protocolo O Java e o CORBA, contudo, funcionam bem na Net. É necessário ter o modelo de segurança do Java. O CORBA é mais difícil de desenvolver do que o ActiveX Ferramentas mais caras, porém mais escalonáveis com os servidores UNIX.
Exemplo típico de uso do CORBA Armazenagem do mainframe: Pedidos, Produto Disponibilidade Sistema UNIX: Emissão de pedidos Processamento Não suportado Sem Y2K Único programa com interface para o mainframe! Consulta SQL em separado para cada campo no formulário
Uso típico do CORBA, continuação Substituir EZBridge com os ORBS CORBA Necessita apenas 6 objetos Usar os ORBs CORBA entre o UNIX e os PCs Windows
Activex/COM versus CORBA ActiveX: Separa a interface do objeto da implementação do objeto, como no CORBA. Possui IDL, não a mesma do CORBA IDL e não interopera. Os objetos do ActiveX não são objetos verdadeiros; eles têm métodos mas não atributos. Os objetos do ActiveX estão presentes como um grupo de funções relacionadas. Os clientes recebem um indicador (identificador) para acessar as funções Ao reconectar, os atributos não são preservados a partir da última vez A biblioteca do tipo COM é essencialmente o Repositório da Interface do CORBA. Biblioteca do tipo COM para consultas dos clientes, para descobrir as interfaces e os parâmetros dos objetos. O registro do COM é similar ao Repositório de Implementação do CORBA.
Resumo ActiveX/COM Dominante em desktop e para aplicativos centralizados em PC. Algumas restrições técnicas (atributos, descoberta). Componentes no mercado para desktops: gráficos, dados, displays, etc. Aproximação bottom-up: aperfeiçoamentos incrementais nas interfaces entre as interfaces de desktop. CORBA Usado no UNIX e no mundo dos servidores IIOP construída na Netscape Componentes no mercado para sistemas de grande porte: faturamento, finanças, etc. Aproximação top-down: arquitetura geral conduzindo a serviços específicos. Ambos são substituídos pelo SOAP, UDDI, WSDL e ebxml.