COM, DCOM, COM+

1. COM, DCOM, COM+ José de Anchieta Isaac de Lima Oliveira Filho André Gustavo Pereira HumbertoNunesFilho

2. Sumário • Contextualização • COM • DCOM • COM+ • Considerações finais • Referências

3. Contextualização • Em 1987, DDE (Dynamic Data Exchange)‏ • Compartilhamento de dados entre aplicações • (Object Link Embbeding) OLE 1.0 • Evolução da DDE • Não possuia limitação no compartilhamento dos dados • Noção de embarcado • Utilizavam Tabelas de Funções Virtuais (Vtables)‏

4. Contextualização • OLE passou a ser OLE2 com novos recursos • COM (Component Object Model)‏ • Possibilidade de reuso de componentes • DCOM • O programador se preocupa apenas com a lógica de negócio • Já possui implementado os padrões de rede de baixo nível

5. Contextualização • MTS (Microsoft Transaction Services)‏ • Segurança • Escalabilidade • COM+ (COM + MTS)‏

6. COM(Component Object Model) Isaac de Lima Oliveira Filho

7. Definições • Arquitetura de softtware independente da plataforma de utilização, que permite desenvolver componentes de objetos que podem interagir com outras aplicações. • Comunicação entre processos • COM especifica um binário padrão para interfaces dinâmicas para garantir a interoperabilidade de objetos • Identificadores de classe (CLSIDs), que são identificadores globais únicos (GUID). • Cada componente COM expõe sua funcionalidade através de uma ou mais interfaces. • MIDL(Compilador COM para IDL)‏ 7

8. GUID 128 bits Estrutura 8

9. Propriedades • Reflexivas, simétricas e transitivas. • Um arquivo IDL permite que desenvolvedores definam classes orientadas a objeto, interfaces, estruturas, enumerações e outros tipos definidos pelo utilizador, independentemente da linguagem de programação. • Reusabilidades de componentes • Encapslamento de dados e de seu processomento através dos ponteiros de interface 9

10. Interface • Uma coleção de funções • Várias interfaces para cada COM class • Todas as classes COM são derivadas da classe IUnkown 10

11. Interface QueryInterface AddRef Release Base para todos as interfaces COM 11

12. Interface IUknonw IDispatch 12

13. Passos para um Objeto COM Simples 13

14. Interagindo Cliente /Servidor 14

15. Cliente X Servidor • Comportamento Síncrono • Chamadas individuais de métodos 15

16. Servidor COM • Serviços que estejam disponíveis na Interface COM. • Três tipos: 16

17. Servidor COM • In-process: implementados com Dynamic Link Libraries(DLL’s), servidor carregado Dinamicamente. • Out-of-process:programas executáveis. tratado por SCM em computadores também remotos(DCOM). • Windows NT: tratado pelo WINDOWS NT. • Surrogate: In-process pode ocorrer remotamente. 17

18. Servidor COM COMPONETES AUXILIARES 18

19. Cliente • Pode ser feito em qualquer linguagem, desde que possa ter como referencia o objeto COM. 19

20. Abordagem Prática COM • Calculadora • Plataforma Windows • Ferramenta Visual Studio 2005 • ATL (Active Template Library )Wizard COM • Servidor tipo In-process, oferecendo serviço implementado em Visual C++. • Cliente em Visual Basic, chamando quatro operações 20

21. VisualBasic Visual C++ Visual J++ Cliente X Servidor(TesteCOM.dll) Cliente Servidor(Objetos) € Operacoes.cpp / TesteCOM.cpp Métodos (Objetos) Interface COM CANAL LOCAL Operacoes.h/ TesteCOM.h Bliblioteca COMRegsrv32:LOCAL Interface para COM Referência da Bliblioteca Chamada da Função COM TesteCOM.idl TesteCOM.dll 21

22. Cliente X Servidor(Object)

23. DCOM(Distributed Component Object Model) André Gustavo Pereira

24. DCOM • Estende o COM para suportar comunicação entre objetos em máquinas diferentes, através de uma LAN, WAN ou da Internet. • Pode utilizar aplicações COM existentes • COM e DCOM não são propriedades da Microsoft, mas são gerenciados pelo consórcio independente ActiveX Consortium

25. Arquitetura DCOM • Visão Geral

26. DCOM • O gerenciador de serviços de controle (SCM) no cliente conecta ao SCM da máquina remota e solicita a criação do objeto • Para instanciar objetos em máquinas remotas, é necessário conhecer o nome do servidor e o identificador da classe (CLSID)‏ • O nome do servidor pode ser obtido de três formas: • Configuração fixa no sistema de registro ou no DCOM Class Store • Parâmetro fixo na chamada às funções de criação dos objetos • Nome de uma instância específica (moniker).

27. DCOM • Registro no Cliente [HKEY_CLASSES_ROOT\CLSID\{<CLSID_AuctionServer>}] "AppID"="{<APPID_AuctionServer>}" [HKEY_CLASSES_ROOT \APPID\{<APPID_AuctionServer>}] "RemoteServerName"="auctions.r.us.com"

28. DCOM • Código no Cliente IAuction* pAuction = NULL; HRESULT hr=CoCreateInstance( CLSID_AuctionService, // Request an instance of class CLSID_AuctionService NULL, // No aggregation. CLSCTX_SERVER, // Any server is fine. IID_IAuction, // Ask for an interface of type IID_IAuction (void**) &pAuction ); // Pointer to returned interface pointer.

29. Arquitetura DCOM

30. DCOM • Independência de localização

31. Marshaling e Unmarshaling • Baseado no padrão DCE RPC: • A assinatura do método é descrita em IDL • São gerados o proxy e o stub • Um ponteiro para a interface é utilizado para acessar o proxy • O processo de marshaling pode ser customizado. Isso pode ser necessário na comunicação com aplicações que não utilizam o padrão DCE RPC. • Referências estáticas podem ser passadas por valor ao invés de acessadas remotamente (Ex: monikers)‏

32. Gerenciamento de Comunicação • Cada componente possui um contador de referências para controlar a quantidade de clientes conectados em um determinado momento. Quando este contador possui valor zero, o respectivo componente pode ser liberado da memória. • DCOM utiliza um protocolo de ping para detectar se o cliente ainda está ativo

33. Gerenciamento de Comunicação • Um componente pode ser tanto um provedor como um consumidor de uma funcionalidade (fluxo de informações bidirecionais) • A comunicação pode ser síncrona ou assíncrona (a partir do Windows 2000)‏

34. Concorrência • Apartment: associação entre um objeto COM e uma thread ou um grupo de threads • Single-Threaded Apartments: • Uma única thread controla a chamada aos métodos do objeto • Uma única thread pode controlar todas as instâncias, ou somente uma • Chamadas feitas de outras threads são enfileiradas quando o componente está em execução • Todos os métodos são sincronizados

35. Concorrência • Multithreaded Apartment • Várias threads podem chamar métodos de um objeto • O objeto deve sincronizar a execução dos métodos, quando necessário

36. Escalabilidade • Multiprocessamento Simétrico (SMP): gerenciamento de fila de threads para requisições • Para componentes “sem estado”, é possível executar múltiplas cópias em máquinas diferentes

37. Escalabilidade • Alguns componentes críticos podem ser isolados em servidores dedicados sem necessidade de recompilação

38. Escalabilidade • Inicialmente, uma única máquina servidora pode armazenar todos os componentes da aplicação. Com o aumento na demanda, tais componentes podem ser distribuídos em novos servidores.

39. Escalabilidade • Novas interfaces podem ser acrescentadas a um componente, sem interferir no acesso às interfaces anteriores. Isso permite que diferentes versões do mesmo componente sejam utilizadas simultaneamente

40. Desempenho • COM possui um mecanismo próprio para chamada remota de procedimentos (RPC) orientada a objetos • O protocolo de comunicação preferencialmente utilizado pelo DCOM é o UDP • Uma única mensagem de ping é enviada para um determinado cliente, independente da quantidade de componentes acessados no servidor • Múltiplos acessos a métodos remotos podem ser empacotados pelo proxy em uma única chamada

41. Desempenho • Um componente pode conectar outros dois componentes diretamente, funcionando como um diretório de serviços • Quando um mesmo componente estiver sendo executado em mais de um servidor, um “broker” pode decidir qual das referências deve ser utilizada

42. Segurança • DCOM utiliza o framework de segurança estensível do Windows NT • O DCOM encapsula os requisitos de segurança dos componentes • A lista de acesso aos componentes (ACL) é armazenada • A arquitetura de segurança do Windows NT suporta diversos provedores de segurança que podem ser utilizados em conjunto com protocolos padronizados da Internet.

43. Segurança

44. Balanceamento de Carga • Principais técnicas de balanceamento: isolamento de componentes críticos, execução paralela e pipeline de processos seqüenciais. • Balanceamento estático: um usuário acessa um servidor específico de uma aplicação, independente das condições atuais da rede • Um componente de referência pode estabelecer a conexão do cliente com um determinado servidor

45. Balanceamento de Carga • Balanceamento Dinâmico: o componente de referência indica qual servidor deve ser conectado através de informações como a topologia de rede, estatísticas sobre demandas passadas, tempo de leitura do servidor, etc. • Balanceamento dinâmico não requer intervenção de um administrador • Outra alternativa é a utilização do proxy para interceptar a chamada a um método e redirecioná-lo para outro servidor.

46. Tolerância a Falhas

47. Tolerância a Falhas • Utiliza um mecanismo próprio de ping. • Uma técnica pode ser implementada utilizando o componente de redirecionamento. • Outra técnica é ter duas cópias do mesmo componente servidor sendo executadas em máquinas diferentes, processando a mesma informação (hot backup)‏

48. Desenvolvimento • A localização de cada componente pode ser modificada com uma simples mudança de configuração. • Clientes podem ser atualizados através de repositórios (class store)‏ • O componente de redirecionamento pode ser utilizado para retornar o componente apropriado para o cliente

49. Neutralidade de Protocolo • DCOM pode utilizar qualquer protocolo de transporte, incluindo TCP/IP, UDP, IPX/SPX e NetBIOS • Baseado em DCE RPC

50. Neutralidade de Plataforma • DCOM é aberto a todas as abordagens de desenvolvimento entre plataformas • Foi definido um padrão binário por plataforma.