DCOM
Origem: Wikipédia, a enciclopédia livre.
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.
Índice |
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
[editar] 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.
