DCOM: diferenças entre revisões
m Bot: Adicionando: de, en, es, hu, it, nl, pl, tr |
{{esboço-informática}} Ver discussão. |
||
Linha 1: | Linha 1: | ||
'''DCOM''' ('''''D'''istributed '''c'''omponent '''o'''bject '''m'''odel'') é uma tecnologia proprietária da [[Microsoft]] para criação de [[Componente de software|componentes de software]] distribuídos em computadores interligados em rede. O DCOM é uma extensão do [[Component Object Model|COM]] (também da Microsoft) para a comunicação entre objetos em [[computação distribuída|sistemas distribuídos]]. A tecnologia DCOM foi substituída, na plataforma de desenvolvimento [[Microsoft .NET|.NET]], pela [[API]] [[.NET Remoting]]. |
|||
Microsoft DCOM (Distributed Component Object Model) é uma extensão do Microsoft COM para a comunicação entre objetos em diferentes computadores, conectados a uma rede local (LAN), uma WAN ou à Internet. |
|||
DCOM é utilizado na construção de aplicações em 3 camadas, de forma a centralizar regras de negócio e processos, obter escalabilidade e facilitar a manutenção. |
|||
Funcionamento |
|||
DCOM funciona de forma transparente tanto para a aplicação cliente quanto para o servidor, que são codificados de acordo com o COM. |
|||
Localização de Objetos |
|||
Assim como no COM, cada classe possui um identificador globalmente único (GUID) de 128 bits, chamado de Class ID (CLSID). A aplicação cliente informa o GUID do objeto desejado e, opcionalmente, o endereço do servidor que tem o arquivo executável ou DLL e que será responsável pela sua execução. |
|||
O SCM (Service Control Manager) no computador cliente se conecta ao SCM no computador servidor, requisita a criação do objeto e retorna um ponteiro para um objeto proxy local, que implementa a mesma interface do objeto remoto, para a aplicação cliente. Caso a aplicação cliente não tenha informado o endereço do servidor, o SCM obtém essa informação no registro do Windows. |
|||
A presença da informação sobre em que computador um objeto será executado fora do código facilita a manutenção já que essa informação pode ser alterada sem que a aplicação cliente seja recompilada e reinstalada. Além disso, aplicações criadas utilizando COM podem ser distribuídas sem reescrita de código ou recompilação, apenas com a alteração da informação de configuração. |
|||
Chamada Remota de Métodos |
|||
Quando a aplicação cliente chama um método do objeto remoto, o objeto proxy precisa efetuar a serialização (marshaling) dos parâmetros para que eles possam ser transmitidos pela rede. Os parâmetros podem ser tipos simples, mas também podem ser arrays ou objetos complexos, compostos de vários objetos (inclusive com referências circulares). |
|||
No servidor, um objeto proxy (chamado de stub) realiza a desserialização (unmarshaling) dos parâmetros, chama o método do objeto, serializa os parâmetros de saída e transmite-os para o computador cliente. No cliente, o objeto proxy desserializa o retorno do método e repassa esses dados para a aplicação cliente. |
|||
O mecanismo de serialização do DCOM foi construído a partir da infraestrutura de RPC (Remote Procedure Call) definida no padrão DCE (Distributed Computing Environment). |
|||
Se uma aplicação cliente (no computador A) realiza uma chamada remota a um método (de um objeto no computador B) que retorna um ponteiro para um objeto em execução em outro computador (C), após a desserialização a aplicação cliente pode chamar remotamente métodos do objeto no computador C. |
|||
Visão Geral da Arquitetura |
|||
Assim como feito no COM, a aplicação cliente cria objetos através de uma chamada à função CoCreateInstance, que utiliza o SCM. |
|||
O SCM no computador cliente se comunica com o SCM no computador servidor que utiliza a função CoCreateInstance para criar o servidor COM desejado. |
|||
A aplicação cliente recebe um ponteiro para um objeto proxy, que implementa a mesma interface do servidor COM e é responsável pela serialização dos parâmetros de entrada, pela utilização das funções do DCOM para comunicação com o computador servidor e pela desserialização dos parâmetros de saída. |
|||
Um objeto stub é responsável por desserializar os parâmetros de entrada das chamadas de métodos do servidor COM, por efetuar a chamada local, por serializar os parâmetros de saída e por utilizar as funções do DCOM para comunicação com o computador cliente. |
|||
O DCOM pode ser utilizado na construção de aplicações em 3 camadas, de forma a centralizar as regras de negócio e processos, obter escalabilidade e facilitar a manutenção. |
|||
Figura 1: Visão geral da arquitetura utilizada pelo DCOM. Fonte: Horstmann, M., e Kirtland, M.: DCOM Architecture. |
|||
==Arquitetura== |
|||
Gerência de Conexão |
|||
O DCOM funciona de forma transparente tanto para a aplicação [[cliente]] quanto para o [[servidor]], que são codificados de acordo com o padrão COM. |
|||
COM realiza a liberação de memória alocada não mais utilizada (garbage collection) através da contagem de referências, com chamadas aos métodos AddRef e Release da interface IUnknown, implementada por todas as classes de objetos COM. |
|||
Para melhorar a performance da comunicação e suportar o término anormal de aplicações cliente, DCOM utiliza pinging e o agrupamento de chamadas de contagem de referência. |
|||
===Visão geral=== |
|||
Gerência de Concorrência |
|||
Assim como feito no COM, a aplicação cliente cria objetos através de uma chamada à função CoCreateInstance, que utiliza o SCM (Service Control Manager). |
|||
Do ponto de vista do programador, a gerência de concorrência no DCOM funciona da mesma forma que o COM. |
|||
O SCM no computador cliente se comunica com o SCM no computador servidor que utiliza a função CoCreateInstance para criar o servidor COM desejado. |
|||
A aplicação cliente recebe um ponteiro para um objeto ''[[proxy]]'', que implementa a mesma [[interface]] do servidor COM e é responsável pela [[serialização]] dos parâmetros de entrada, pela utilização das funções do DCOM para comunicação com o computador servidor e pela "desserialização" dos parâmetros de saída. |
|||
Um objeto ''[[stub]]'' é responsável por "desserializar" os parâmetros de entrada das chamadas de [[Método (programação)|métodos]] do servidor COM, por efetuar a chamada local, por serializar os parâmetros de saída e por utilizar as funções do DCOM para comunicação com o computador cliente. |
|||
O COM realiza a liberação de [[Memória (computador)|memória]] alocada não mais utilizada (''[[garbage collection]]'') através da contagem de referências, com chamadas aos métodos AddRef e Release da interface IUnknown, implementada por todas as classes de objetos COM. |
|||
Para melhorar a performance da comunicação e suportar o término anormal de aplicações cliente, DCOM utiliza ''[[ping|pinging]]'' e o agrupamento de chamadas de contagem de referência. |
|||
===Localização de objetos=== |
|||
Assim como no COM, cada [[classe (programação)|classe]] possui um identificador globalmente único (GUID) de 128 bits, chamado de Class ID (CLSID). A aplicação cliente informa o GUID do [[objeto]] desejado e, opcionalmente, o endereço do servidor que tem o [[executável|arquivo executável]] ou [[DLL]] e que será responsável pela sua execução. O SCM no computador cliente se conecta ao SCM no computador servidor, requisita a criação do objeto e retorna um [[ponteiro]] para um objeto ''proxy'' local, que implementa a mesma interface do objeto remoto, para a aplicação cliente. Caso a aplicação cliente não tenha informado o endereço do servidor, o SCM obtém essa informação no registro do [[Windows]]. |
|||
===Chamada remota de métodos=== |
|||
Quando a aplicação cliente chama um método do objeto remoto, o objeto ''proxy'' precisa efetuar a [[serialização]] (''marshaling'') dos parâmetros para que eles possam ser transmitidos pela rede. Os parâmetros podem ser tipos simples, mas também podem ser ''[[array]]s'' ou objetos complexos, compostos de vários objetos (inclusive com referências circulares). |
|||
No servidor, um objeto ''proxy'' (chamado de ''stub'') realiza a "desserialização" (''unmarshaling'') dos parâmetros, chama o método do objeto, serializa os parâmetros de saída e transmite-os para o computador cliente. No cliente, o objeto proxy "desserializa" o retorno do método e repassa esses dados para a aplicação cliente. O mecanismo de serialização do DCOM foi construído a partir da infraestrutura de [[Chamada de procedimento remoto|RPC]] (Remote Procedure Call) definida no padrão DCE (Distributed Computing Environment). |
|||
Se uma aplicação cliente (no computador A) realiza uma chamada remota a um método (de um objeto no computador B) que retorna um ponteiro para um objeto em execução em outro computador (C), após a desserialização a aplicação cliente |
|||
pode chamar remotamente métodos do objeto no computador C. |
|||
===Gerência de Concorrência=== |
|||
Do ponto de vista do programador, a gerência de concorrência no DCOM funciona da mesma forma que o COM. |
|||
Na opção Single-Threaded Apartment (STA) cada método de um objeto não recebe chamadas simultâneas, ou seja, cada objeto executa em uma thread. No entanto, várias instâncias do objeto podem ser criadas para atender a requisições simultâneas. Na opção STA, main thread only, todas as instâncias são criadas na mesma thread. |
Na opção Single-Threaded Apartment (STA) cada método de um objeto não recebe chamadas simultâneas, ou seja, cada objeto executa em uma thread. No entanto, várias instâncias do objeto podem ser criadas para atender a requisições simultâneas. Na opção STA, main thread only, todas as instâncias são criadas na mesma thread. |
||
Na opção Multi-Threaded Apartment (MTA), um método pode receber várias chamadas ao mesmo tempo e deve ser codificado com a utilização de sincronização caso utilize algum recurso compartilhado, como um campo do objeto. |
Na opção Multi-Threaded Apartment (MTA), um método pode receber várias chamadas ao mesmo tempo e deve ser codificado com a utilização de sincronização caso utilize algum recurso compartilhado, como um campo do objeto. |
||
Segurança |
|||
===Segurança=== |
|||
O controle de acesso, que verifica se um usuário está autorizado a executar um método, pode ser configurado de forma declarativa ou ser embutido no código. O controle de criação de objetos somente pode ser feito de forma declarativa para evitar ataques de negação de serviço. |
|||
O controle de acesso, que verifica se um usuário está autorizado a executar um método, pode ser configurado de forma declarativa ou ser embutido no código. O controle de criação de objetos somente pode ser feito de forma declarativa para evitar ataques de negação de serviço. |
|||
DCOM fornece o serviço de autenticação de clientes. A autenticação pode ser configurada para funcionar com vários security providers, dentre eles o Windows NT LAN Manager (NTLM). Na configuração padrão, a autenticação ocorre no estabelecimento da conexão. No entanto, ela pode ser configurada para ocorrer em cada chamada. |
|||
Para a restrição de acesso aos recursos gerenciados pelo sistema operacional, o objeto remoto pode assumir a identidade do criador, o que pode ser útil quando o servidor é disponibilizado em uma rede local, ou uma identidade padrão, o que pode ser útil quando o servidor é disponibilizado na Internet. |
|||
O DCOM fornece o serviço de autenticação de clientes. A autenticação pode ser configurada para funcionar com vários security providers, dentre eles o Windows NT LAN Manager (NTLM). Na configuração padrão, a autenticação ocorre no estabelecimento da conexão. No entanto, ela pode ser configurada para ocorrer em cada chamada. |
|||
Clientes ou objetos podem requisitar que os pacotes de dados possuam informação adicional que garante integridade e criptografia dos pacotes. |
|||
Como um servidor COM pode assumir a identidade do cliente, para prevenir o uso das credenciais do cliente por objetos programados de forma maliciosa, o cliente pode indicar se o objeto pode autenticá-lo e utilizar a sua identidade. |
|||
Para a restrição de acesso aos recursos gerenciados pelo sistema operacional, o objeto remoto pode assumir a identidade do criador, o que pode ser útil quando o servidor é disponibilizado em uma rede local, ou uma identidade padrão, o que pode ser útil quando o servidor é disponibilizado na Internet. |
|||
Pilha de Comunicação Utilizada pelo DCOM |
|||
O protocolo do DCOM, chamado de ORPC (Object RPC), estende o protocolo DCE RPC. Os dados serializados nos pacotes ORPC são armazenados no formato Network Data Representation (NDR). |
|||
Clientes ou objetos podem requisitar que os pacotes de dados possuam informação adicional que garante integridade e criptografia dos pacotes. |
|||
O compilador MSIDL (Microsoft Interface Definition Language) é utilizado para a criação dos objetos proxy e stub, a partir da interface do servidor COM, que serializam e desserializam parâmetros e realizam a comunicação entre a aplicação cliente e o servidor COM. |
|||
Segundo [6], DCOM utiliza UDP na comunicação entre duas máquinas com sistema operacional Windows NT 4 e TCP na comunicação entre duas máquinas com outros sistemas operacionais, como Windows 2000, 95, 98 e UNIX. |
|||
Como um servidor COM pode assumir a identidade do cliente, para prevenir o uso das credenciais do cliente por objetos programados de forma maliciosa, o cliente pode indicar se o objeto pode autenticá-lo e utilizar a sua identidade. |
|||
Instalação e Configuração de Componentes Remotos |
|||
O componente remoto deve primeiramente ser registrado no computador servidor, com a utilização de um dos seguintes comandos: |
|||
===Pilha de comunicação utilizada pelo DCOM=== |
|||
regsvr32 <dll> |
|||
<arquivo executável> /regserver |
|||
O protocolo do DCOM, chamado de ORPC (Object RPC), estende o protocolo DCE RPC. Os dados serializados nos pacotes ORPC são armazenados no formato Network Data Representation (NDR). |
|||
O compilador MSIDL (Microsoft Interface Definition Language) é utilizado para a criação dos objetos proxy e stub, a partir da interface do servidor COM, que serializam e desserializam parâmetros e realizam a comunicação entre a aplicação cliente e o servidor COM. |
|||
Segundo [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomfirewall.asp], DCOM utiliza [[User Datagram Protocol |UDP]] na comunicação entre duas máquinas com sistema operacional Windows NT 4 e TCP na comunicação entre duas máquinas com outros sistemas operacionais, como [[Windows 2000]], [[Windows 95]], [[Windows 98]] e [[UNIX]]. |
|||
==Instalação e configuração de componentes remotos== |
|||
O componente remoto deve primeiramente ser registrado no computador servidor, com a utilização de um dos seguintes comandos: |
|||
regsvr32 <dll> <arquivo executável> /regserver |
|||
O computador remoto deve ter uma conta com o mesmo nome de usuário e senha do usuário que irá utilizar a aplicação cliente (o que é verdade em redes locais com domínio) ou as configurações de segurança devem ser alteradas no computador servidor. |
O computador remoto deve ter uma conta com o mesmo nome de usuário e senha do usuário que irá utilizar a aplicação cliente (o que é verdade em redes locais com domínio) ou as configurações de segurança devem ser alteradas no computador servidor. |
||
Utilitário DCOMCnfg |
|||
==Utilitário DCOMCnfg== |
|||
O utilitário DCOMCnfg, que faz parte do Windows 2000 e pode ser instalado no Windows 95, permite a configuração de componentes remotos sem a edição direta do registro do Windows. |
O utilitário DCOMCnfg, que faz parte do Windows 2000 e pode ser instalado no Windows 95, permite a configuração de componentes remotos sem a edição direta do registro do Windows. |
||
Figura 2: O utilitário DCOMCnfg. |
|||
O arquivo executável ou DLL com o componente remoto deve ser primeiramente registrado no computador cliente com a utilização de um dos seguintes comandos: |
O arquivo executável ou DLL com o componente remoto deve ser primeiramente registrado no computador cliente com a utilização de um dos seguintes comandos: |
||
regsvr32 <dll> |
|||
<arquivo executável> /regserver |
regsvr32 <dll> <arquivo executável> /regserver |
||
Para efetuar esse registro, o arquivo executável ou DLL deve ser copiado para o computador cliente ou deve ser utilizada uma pasta compartilhada. |
|||
Para efetuar esse registro, o arquivo executável ou DLL deve ser copiado para o computador cliente ou deve ser utilizada uma pasta compartilhada. |
|||
Então, o utilitário DCOMCnfg deve ser executado e na aba “Localidade” deve ser selecionada a opção “Executar aplicação no seguinte computador” e informado o nome ou endereço IP do servidor. |
|||
Edição Direta do Registro do Windows |
|||
Então, o utilitário DCOMCnfg deve ser executado e na aba “Localidade” deve ser selecionada a opção “Executar aplicação no seguinte computador” e informado o nome ou endereço IP do servidor. |
|||
==Edição direta do registro do Windows== |
|||
O endereço do servidor responsável pela execução de um objeto é configurado no registro do Windows com a adição das seguintes chaves: |
O endereço do servidor responsável pela execução de um objeto é configurado no registro do Windows com a adição das seguintes chaves: |
||
[HKEY_CLASSES_ROOT\APPID\{<appid>}] |
|||
"RemoteServerName"="<nome ou endereço IP do servidor>" |
[HKEY_CLASSES_ROOT\APPID\{<appid>}] "RemoteServerName"="<nome ou endereço IP do servidor>" |
||
[HKEY_CLASSES_ROOT\CLSID\{<clsid>}] |
[HKEY_CLASSES_ROOT\CLSID\{<clsid>}] "AppId"="<appid>" |
||
"AppId"="<appid>" |
|||
O parâmetro existe para o compartilhamento de informações de segurança e de localidade de execução entre vários objetos, de forma a eliminar redundância no armazenamento dessas informações. |
|||
Exemplo |
|||
==Exemplo== |
|||
Para o teste do DCOM, foi criado um servidor COM que possui um método que diz a hora do computador onde ele está executando e uma aplicação cliente que ajusta o relógio do computador com o resultado da chamada do método do servidor. |
|||
Para o teste do DCOM, foi criado um servidor COM que possui um método que diz a hora do computador onde ele está executando e uma aplicação cliente que ajusta o relógio do computador com o resultado da chamada do método do servidor. |
|||
Implementação |
|||
Abaixo, segue o código fonte da aplicação cliente e do servidor COM, ambos escritos em Delphi. |
|||
===Implementação=== |
|||
Aplicação Cliente |
|||
Abaixo, segue o código fonte da aplicação cliente e do servidor COM, ambos escritos em Delphi: |
|||
unit unForm; |
|||
interface |
|||
unit unForm; |
|||
uses |
|||
interface |
|||
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ProjRelogio_TLB, ComObj; |
|||
uses |
|||
type |
|||
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ProjRelogio_TLB, ComObj; |
|||
TForm1 = class(TForm) |
|||
type |
|||
Label1: TLabel; |
|||
TForm1 = class(TForm) |
|||
Button1: TButton; |
|||
Label1: TLabel; |
|||
procedure FormCreate(Sender: TObject); |
|||
Button1: TButton; |
|||
procedure Button1Click(Sender: TObject); |
|||
procedure FormCreate(Sender: TObject); |
|||
private |
|||
procedure Button1Click(Sender: TObject); |
|||
{ Private declarations } |
|||
private |
|||
public |
|||
{ Private declarations } |
|||
public |
|||
{ Public declarations } |
{ Public declarations } |
||
end; |
|||
var |
|||
var |
|||
Form1: TForm1; |
Form1: TForm1; |
||
vServidorRelogio: IServidorRelogio; |
vServidorRelogio: IServidorRelogio; |
||
implementation |
implementation |
||
{$R *.DFM} |
{$R *.DFM} |
||
procedure TForm1.FormCreate(Sender: TObject); |
|||
procedure TForm1.FormCreate(Sender: TObject); |
|||
begin |
|||
begin |
|||
vServidorRelogio := CreateComObject(CLASS_ServidorRelogio) as IServidorRelogio; |
|||
vServidorRelogio := CreateComObject(CLASS_ServidorRelogio) as IServidorRelogio; |
|||
end; |
|||
end; |
|||
procedure TForm1.Button1Click(Sender: TObject); |
|||
var dataHora: TDateTime; |
|||
procedure TForm1.Button1Click(Sender: TObject); |
|||
var dataHora: TDateTime; |
|||
res: integer; |
res: integer; |
||
st: TSystemTime; |
st: TSystemTime; |
||
begin |
begin |
||
res := vServidorRelogio.pegaDataHora(dataHora); |
|||
if res = S_OK then |
|||
begin |
|||
DateTimeToSystemTime(dataHora, st); |
|||
SetLocalTime(st); |
|||
end |
|||
else |
|||
ShowMessage('ERRO'); |
|||
end; |
|||
end. |
|||
Servidor COM: |
|||
unit unServidorRelogio; |
|||
interface |
|||
uses Windows, ActiveX, Classes, ComObj, ProjRelogio_TLB, StdVcl, SysUtils; |
|||
type |
|||
TServidorRelogio = class(TTypedComObject, IServidorRelogio) |
|||
protected |
|||
function pegaDataHora(out resultado: TDateTime): HResult; stdcall; |
|||
{Declare IServidorRelogio methods here} |
|||
end; |
|||
implementation |
|||
uses ComServ; |
|||
function TServidorRelogio.pegaDataHora(out resultado: TDateTime): HResult; |
|||
begin |
begin |
||
resultado := Now; |
|||
DateTimeToSystemTime(dataHora, st); |
|||
Result := S_OK; |
|||
SetLocalTime(st); |
|||
end |
end; |
||
initialization |
|||
else |
|||
TTypedComObjectFactory.Create(ComServer, TServidorRelogio, Class_ServidorRelogio, ciMultiInstance, tmApartment); |
|||
ShowMessage('ERRO'); |
|||
end |
end. |
||
end. |
|||
Configuração: |
|||
Servidor COM |
|||
unit unServidorRelogio; |
|||
Para a configuração do acesso ao servidor COM no computador cliente, foi criado um arquivo de alteração do registro do Windows. A seguir, o conteúdo do arquivo de configuração: |
|||
interface |
|||
uses Windows, ActiveX, Classes, ComObj, ProjRelogio_TLB, StdVcl, SysUtils; |
|||
REGEDIT4 [HKEY_CLASSES_ROOT\APPID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}] "RemoteServerName"="wprjo3af" |
|||
type |
|||
[HKEY_CLASSES_ROOT\CLSID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}] "AppId"="{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}" |
|||
TServidorRelogio = class(TTypedComObject, IServidorRelogio) |
|||
[HKEY_CLASSES_ROOT\CLSID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}\LocalServer32]=- |
|||
protected |
|||
function pegaDataHora(out resultado: TDateTime): HResult; stdcall; |
|||
O servidor foi registrado no computador cliente e, em seguida, foi executado o arquivo de configuração. |
|||
{Declare IServidorRelogio methods here} |
|||
end; |
|||
{{esboço-informática}} |
|||
implementation |
|||
uses ComServ; |
|||
[[Categoria:Computação distribuída]] |
|||
function TServidorRelogio.pegaDataHora(out resultado: TDateTime): HResult; |
|||
begin |
|||
resultado := Now; |
|||
Result := S_OK; |
|||
end; |
|||
initialization |
|||
TTypedComObjectFactory.Create(ComServer, TServidorRelogio, Class_ServidorRelogio, ciMultiInstance, tmApartment); |
|||
end. |
|||
Configuração |
|||
Para a configuração do acesso ao servidor COM no computador cliente, foi criado um arquivo de alteração do registro do Windows. A seguir, o conteúdo do arquivo de configuração: |
|||
REGEDIT4 |
|||
[HKEY_CLASSES_ROOT\APPID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}] |
|||
"RemoteServerName"="wprjo3af" |
|||
[HKEY_CLASSES_ROOT\CLSID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}] |
|||
"AppId"="{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}" |
|||
[HKEY_CLASSES_ROOT\CLSID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}\LocalServer32]=- |
|||
O servidor foi registrado no computador cliente e, em seguida, foi executado o arquivo de configuração. |
|||
[[de:Distributed Component Object Model]] |
[[de:Distributed Component Object Model]] |
Revisão das 01h34min de 12 de setembro de 2006
DCOM (Distributed component object model) é uma tecnologia proprietária da Microsoft para criação de componentes de software distribuídos em computadores interligados em rede. O DCOM é uma extensão do COM (também da Microsoft) para a comunicação entre objetos em sistemas distribuídos. A tecnologia DCOM foi substituída, na plataforma de desenvolvimento .NET, pela API .NET Remoting.
O DCOM pode ser utilizado na construção de aplicações em 3 camadas, de forma a centralizar as regras de negócio e processos, obter escalabilidade e facilitar a manutenção.
Arquitetura
O DCOM funciona de forma transparente tanto para a aplicação cliente quanto para o servidor, que são codificados de acordo com o padrão COM.
Visão geral
Assim como feito no COM, a aplicação cliente cria objetos através de uma chamada à função CoCreateInstance, que utiliza o SCM (Service Control Manager).
O SCM no computador cliente se comunica com o SCM no computador servidor que utiliza a função CoCreateInstance para criar o servidor COM desejado.
A aplicação cliente recebe um ponteiro para um objeto proxy, que implementa a mesma interface do servidor COM e é responsável pela serialização dos parâmetros de entrada, pela utilização das funções do DCOM para comunicação com o computador servidor e pela "desserialização" dos parâmetros de saída.
Um objeto stub é responsável por "desserializar" os parâmetros de entrada das chamadas de métodos do servidor COM, por efetuar a chamada local, por serializar os parâmetros de saída e por utilizar as funções do DCOM para comunicação com o computador cliente.
O COM realiza a liberação de memória alocada não mais utilizada (garbage collection) através da contagem de referências, com chamadas aos métodos AddRef e Release da interface IUnknown, implementada por todas as classes de objetos COM.
Para melhorar a performance da comunicação e suportar o término anormal de aplicações cliente, DCOM utiliza pinging e o agrupamento de chamadas de contagem de referência.
Localização de objetos
Assim como no COM, cada classe possui um identificador globalmente único (GUID) de 128 bits, chamado de Class ID (CLSID). A aplicação cliente informa o GUID do objeto desejado e, opcionalmente, o endereço do servidor que tem o arquivo executável ou DLL e que será responsável pela sua execução. O SCM no computador cliente se conecta ao SCM no computador servidor, requisita a criação do objeto e retorna um ponteiro para um objeto proxy local, que implementa a mesma interface do objeto remoto, para a aplicação cliente. Caso a aplicação cliente não tenha informado o endereço do servidor, o SCM obtém essa informação no registro do Windows.
Chamada remota de métodos
Quando a aplicação cliente chama um método do objeto remoto, o objeto proxy precisa efetuar a serialização (marshaling) dos parâmetros para que eles possam ser transmitidos pela rede. Os parâmetros podem ser tipos simples, mas também podem ser arrays ou objetos complexos, compostos de vários objetos (inclusive com referências circulares).
No servidor, um objeto proxy (chamado de stub) realiza a "desserialização" (unmarshaling) dos parâmetros, chama o método do objeto, serializa os parâmetros de saída e transmite-os para o computador cliente. No cliente, o objeto proxy "desserializa" o retorno do método e repassa esses dados para a aplicação cliente. O mecanismo de serialização do DCOM foi construído a partir da infraestrutura de RPC (Remote Procedure Call) definida no padrão DCE (Distributed Computing Environment).
Se uma aplicação cliente (no computador A) realiza uma chamada remota a um método (de um objeto no computador B) que retorna um ponteiro para um objeto em execução em outro computador (C), após a desserialização a aplicação cliente pode chamar remotamente métodos do objeto no computador C.
Gerência de Concorrência
Do ponto de vista do programador, a gerência de concorrência no DCOM funciona da mesma forma que o COM. Na opção Single-Threaded Apartment (STA) cada método de um objeto não recebe chamadas simultâneas, ou seja, cada objeto executa em uma thread. No entanto, várias instâncias do objeto podem ser criadas para atender a requisições simultâneas. Na opção STA, main thread only, todas as instâncias são criadas na mesma thread. Na opção Multi-Threaded Apartment (MTA), um método pode receber várias chamadas ao mesmo tempo e deve ser codificado com a utilização de sincronização caso utilize algum recurso compartilhado, como um campo do objeto.
Segurança
O controle de acesso, que verifica se um usuário está autorizado a executar um método, pode ser configurado de forma declarativa ou ser embutido no código. O controle de criação de objetos somente pode ser feito de forma declarativa para evitar ataques de negação de serviço.
O DCOM fornece o serviço de autenticação de clientes. A autenticação pode ser configurada para funcionar com vários security providers, dentre eles o Windows NT LAN Manager (NTLM). Na configuração padrão, a autenticação ocorre no estabelecimento da conexão. No entanto, ela pode ser configurada para ocorrer em cada chamada.
Para a restrição de acesso aos recursos gerenciados pelo sistema operacional, o objeto remoto pode assumir a identidade do criador, o que pode ser útil quando o servidor é disponibilizado em uma rede local, ou uma identidade padrão, o que pode ser útil quando o servidor é disponibilizado na Internet.
Clientes ou objetos podem requisitar que os pacotes de dados possuam informação adicional que garante integridade e criptografia dos pacotes.
Como um servidor COM pode assumir a identidade do cliente, para prevenir o uso das credenciais do cliente por objetos programados de forma maliciosa, o cliente pode indicar se o objeto pode autenticá-lo e utilizar a sua identidade.
Pilha de comunicação utilizada pelo DCOM
O protocolo do DCOM, chamado de ORPC (Object RPC), estende o protocolo DCE RPC. Os dados serializados nos pacotes ORPC são armazenados no formato Network Data Representation (NDR).
O compilador MSIDL (Microsoft Interface Definition Language) é utilizado para a criação dos objetos proxy e stub, a partir da interface do servidor COM, que serializam e desserializam parâmetros e realizam a comunicação entre a aplicação cliente e o servidor COM.
Segundo [1], DCOM utiliza UDP na comunicação entre duas máquinas com sistema operacional Windows NT 4 e TCP na comunicação entre duas máquinas com outros sistemas operacionais, como Windows 2000, Windows 95, Windows 98 e UNIX.
Instalação e configuração de componentes remotos
O componente remoto deve primeiramente ser registrado no computador servidor, com a utilização de um dos seguintes comandos:
regsvr32 <dll> <arquivo executável> /regserver
O computador remoto deve ter uma conta com o mesmo nome de usuário e senha do usuário que irá utilizar a aplicação cliente (o que é verdade em redes locais com domínio) ou as configurações de segurança devem ser alteradas no computador servidor.
Utilitário DCOMCnfg
O utilitário DCOMCnfg, que faz parte do Windows 2000 e pode ser instalado no Windows 95, permite a configuração de componentes remotos sem a edição direta do registro do Windows.
O arquivo executável ou DLL com o componente remoto deve ser primeiramente registrado no computador cliente com a utilização de um dos seguintes comandos:
regsvr32 <dll> <arquivo executável> /regserver
Para efetuar esse registro, o arquivo executável ou DLL deve ser copiado para o computador cliente ou deve ser utilizada uma pasta compartilhada.
Então, o utilitário DCOMCnfg deve ser executado e na aba “Localidade” deve ser selecionada a opção “Executar aplicação no seguinte computador” e informado o nome ou endereço IP do servidor.
Edição direta do registro do Windows
O endereço do servidor responsável pela execução de um objeto é configurado no registro do Windows com a adição das seguintes chaves:
[HKEY_CLASSES_ROOT\APPID\{<appid>}] "RemoteServerName"="<nome ou endereço IP do servidor>" [HKEY_CLASSES_ROOT\CLSID\{<clsid>}] "AppId"="<appid>"
O parâmetro existe para o compartilhamento de informações de segurança e de localidade de execução entre vários objetos, de forma a eliminar redundância no armazenamento dessas informações.
Exemplo
Para o teste do DCOM, foi criado um servidor COM que possui um método que diz a hora do computador onde ele está executando e uma aplicação cliente que ajusta o relógio do computador com o resultado da chamada do método do servidor.
Implementação
Abaixo, segue o código fonte da aplicação cliente e do servidor COM, ambos escritos em Delphi:
unit unForm; interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ProjRelogio_TLB, ComObj; type TForm1 = class(TForm) Label1: TLabel; Button1: TButton; procedure FormCreate(Sender: TObject); procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; vServidorRelogio: IServidorRelogio; implementation {$R *.DFM} procedure TForm1.FormCreate(Sender: TObject); begin vServidorRelogio := CreateComObject(CLASS_ServidorRelogio) as IServidorRelogio; end; procedure TForm1.Button1Click(Sender: TObject); var dataHora: TDateTime; res: integer; st: TSystemTime; begin res := vServidorRelogio.pegaDataHora(dataHora); if res = S_OK then begin DateTimeToSystemTime(dataHora, st); SetLocalTime(st); end else ShowMessage('ERRO'); end; end.
Servidor COM:
unit unServidorRelogio; interface uses Windows, ActiveX, Classes, ComObj, ProjRelogio_TLB, StdVcl, SysUtils; type TServidorRelogio = class(TTypedComObject, IServidorRelogio) protected function pegaDataHora(out resultado: TDateTime): HResult; stdcall; {Declare IServidorRelogio methods here} end; implementation uses ComServ; function TServidorRelogio.pegaDataHora(out resultado: TDateTime): HResult; begin resultado := Now; Result := S_OK; end; initialization TTypedComObjectFactory.Create(ComServer, TServidorRelogio, Class_ServidorRelogio, ciMultiInstance, tmApartment); end.
Configuração:
Para a configuração do acesso ao servidor COM no computador cliente, foi criado um arquivo de alteração do registro do Windows. A seguir, o conteúdo do arquivo de configuração:
REGEDIT4 [HKEY_CLASSES_ROOT\APPID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}] "RemoteServerName"="wprjo3af" [HKEY_CLASSES_ROOT\CLSID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}] "AppId"="{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}" [HKEY_CLASSES_ROOT\CLSID\{0830D08C-AB9A-4309-8B4B-35673BFAD0FC}\LocalServer32]=-
O servidor foi registrado no computador cliente e, em seguida, foi executado o arquivo de configuração.