msdn12_capa.JPG

Clique aqui para ler todos os artigos desta edição

 

Utilizando COM+ nas Aplicações .Net

COM+ – evolução do Microsoft Component Object Model (COM) e do Microsoft Transaction Server (MTS) – atualmente em sua versão 1.5 para os Sistemas Operacionais Windows XP e a família Windows 2003 Server, é um importante serviço de gerenciamento de recursos, projetado inicialmente para soluções desenvolvidas em C++ e Visual Basic.

Durante o desenvolvimento de aplicações corporativas, onde o ambiente distribuído e missão crítica são realidades, a realização de um excelente projeto dos componentes de nossa solução é fundamental para que tenhamos sucesso. É necessário também a integração do aplicativo com um servidor de serviços, que nos auxiliará em questões como o gerenciamento de threads utilizados, distribuição de transações, pool de recursos, segurança e muito mais. É neste contexto que o COM+ se encaixa.

Porém, o COM+ foi projetado para aplicações desenvolvidas em C++ e Visual Basic, ou seja, ele não foi inicialmente projeto para o uso com a tecnologia Microsoft .NET. Mas os requisitos iniciais não mudaram: ainda desenvolvemos soluções corporativas, ainda temos transações distribuídas, ainda precisamos utilizar os recursos de servidores de forma otimizada, além de outras funcionalidades. O fato é que o COM+ continua sendo a ferramenta que de auxilio nestas tarefas e precisamos fazer uso dos seus recursos dentro do ambiente .NET.

Neste artigo vou apresentar os recursos existentes no COM+ e como criar os Serviced Components – componentes de serviços – que são os componentes que utilizam o COM+ na tecnologia Microsoft .NET.

 

Tipos de Aplicações no COM+

Existem 4 tipos de aplicações que são gerenciadas pelo COM+ que definem sua forma de ativação:

§         Server applications

São aplicações que executam em processo próprio e suportam todos os serviços disponibilizados pelo COM+

§         Library applications

São aplicações que executam nos processos criados pelo chamador (aplicação cliente), não sendo explicitamente associadas com processo servidor. Não suportam serviços de acesso remoto ou  queued components

§         Application proxies

São um conjunto de arquivos contendo informações de registro que permitem à um cliente remotamente acessar aplicações servidoras, permitindo assim que uma aplicação servidora possa ser acessada remotamente a partir de um computador cliente. Isto é possível porque, quando executados num cliente, registram informações sobre a aplicação servidora, tais como CLSIDs, ProgIDs, RemoteServerName e informações de ordenamento no computador cliente.

§         COM+ preinstalled applications

São aplicações que já vem instaladas no COM+ com a finalidade de manipular funções internas do computador host. Elas não podem ser apagadas ou modificadas. Alguns exemplos que podemos visualizar são: .Net Utilities, COM+ Explorer, COM+ Utilities, etc.

 

Para o desenvolvimento destas aplicações, dois conceitos do COM+ são fundamentais: Contextos e Modelo de Thread. Contidos nestes, existem ainda outros conceitos secundários, que igualmente estaremos abordando, permitindo assim uma compreensão completa do modelo.

 

Contextos são a “fundação na qual os serviços COM+ são fornecidos”. É definido através de um conjunto propriedades definidas em tempo de execução, associadas aos serviços do COM+ que são utilizados para fornecer serviços à aplicação. Cada objeto COM existente está vinculado à um contexto que o executa e, cada contexto reside dentro de “apartamento” (que é uma coleção de contextos dentro de um processo) do COM+ (Figura 1), sendo que um apartamento pode conter vários contextos e um contexto pode ter vários objetos. São baseadas nas informações do contexto que o COM+ fornece seus serviços, tais como segurança, que representam as necessidades do objeto durante a sua execução.

 

Modelos de Threads são os processos “projetados ao redor de uma coleção de objetos, chamada apartamento” (Figura 1). Um thread é um código que é periodicamente executado dentro de um processo. Assim, um processador executa threads e não processos onde, para cada aplicação 32 bits há ao menos um processo vinculado e neste, sempre haverá um thread, que é o thread primário. As categorias de threads no COM+ são: single-threaded apartment e multithreaded apartment, conhecidos popularmente por STA e MTA. No primeiro caso, os objetos executam no thread onde foram criados, executando um método de cada vez. Na segunda categoria, o objeto pode executar em qualquer thread e permitir que qualquer número de métodos executem simultâneamente.

 

image001.png

Figura 1: COM+ Process Model

 

Uma vez compreendido o modelo do processo do COM+, vamos dar uma olhada no objetivo principal deste artigo: Os serviços oferecidos pelo COM+. Abordaremos apenas 4 deles, que consideramos os que possuem maior demanda nas aplicações. Caso queira se aprofundar no COM+ SDK Documentation, está disponível online no MSDN (http://msdn.microsoft.com/library ? Component Development ? COM+ (Component Services)). Assim sendo, destacamos:

 

§         COM+ Transactions

Uma transação é um conjunto de tarefas relacionadas, onde o sucesso ou falha impacta em todas as partes relacionadas, como uma única unidade. Entender uma transação é entender o que significa a sigla ACID – Atomicidade, Consistência, Isolamento e Durabilidade. Os conceitos e recursos que envolvem uma transação dentro de um sistema são muitos. Envolvem modelos e limites, monitores de processamento de transações (TP Monitors), gerenciadores de transações, gerenciadores de recursos e dispensadores de recursos, tudo isto funcionando de forma sincronizada e fazer tudo isto “na unha” não é muito agradável. O COM+ trata para nós os exatamente estes detalhes “chatos”, tornando fácil a aplicabilidade destes conceitos: Você configura as transações, define seu nível de isolamento, seu time-out, etc.

 

Quando você configura uma transação num componente (através de atributos), você informa ao COM+ qual o nível de proteção requerida para o objeto ativado, onde ele poderá participar de uma transação existente, criar uma nova, ou executar sem a proteção transacional. A tabela abaixo apresenta os “tipos” de configurações disponíveis:

 

Configuração

Descrição

Disabled

Utilizamos esta configuração somente quando queremos garantir que nosso componente nunca acessará o gerenciador de recursos, fazendo com que o COM+ ignore os requerimentos transacionais do componente num determinado contexto em que estiver inserido.

Not Supported

Nesta configuração, o COM+ garante que qualquer objeto criado a partir deste componente nunca participará da transação, independente do status transacional do seu chamador. Este é o valor padrão para todos os componentes.

Supported

Aqui o COM+ garante que qualquer objeto criado a partir do componente participa de uma transação, se ela existir, compartilhando assim, a transação existente.

Required

Quando definimos esta configuração, o COM+ garante que qualquer objeto criado é transacional, inserindo o objeto no contexto do chamador ou criando uma nova transação, caso ela não exista.

Requires New

Por fim, com esta configuração o COM+ garante que qualquer objeto criado a participará de um novo contexto transacional, independente do contexto do objeto chamador. Porém tome cuidado, pois isto não significa que as transações sejam relacionadas. A nova transação criada é completamente independente da anterior, não gerando nenhum efeito sobre a transação que a originou.

 

§         COM+ Just-in-Time Activation

JIT é um recurso do COM+ que permite às aplicações clientes manter referências aos objetos por um longo tempo, sem necessariamente consumir recursos (como por exemplo memória) do servidor. Isto é possível porque o COM+ desativa o objeto ainda que o cliente mantenha uma referência ativa ao objeto, permitindo assim que quando o cliente realizar uma nova chamada, o objeto seja reativado de forma transparente para o cliente.

 

§         COM+ Object Pooling

Object Pooling é um serviço fornecido automaticamente pelo COM+ que permite-nos configurar componentes para possuirem instâncias suas mantidas ativas num pool, prontas para serem utilizadas por qualquer aplicação cliente que o requisite.

Administrativamente, podemos configurar o COM+ especificando características como o tamanho do pool e time-out para a criação de componentes, de forma a permitir que os detalhes da ativação e reuso dos componentes pelo COM+ ocorram como o especificado e assim, possamos monitorar do uso dos recursos disponibilizados.

 

§         COM+ Security

Como não poderia ser diferente, o aspecto da segurança é bem tratado no COM+. E o ideal é que utilizemos as configurações automáticas de segurança diponibilizadas pelo serviço, ao invés de desenvolvermos mecanismos proprietários.

 

O COM+ disponibiliza níveis de checagem de segurança, determinando onde a checagem de acesso à aplicação COM+ é realizada. A tabela abaixo apresenta os níveis de segurança disponibilizados:

 

Nível de segurança

Descrição

Somente no processo

É o valor padrão, onde as propriedades de segurança não serão incluídas no contexto do objeto. Indica que os usuários nos papéis que são atribuidos à aplicação serão adicionados no descritor do processo de segurança.

No processo e no componente

É exatamente o comportamento contrário, permitindo que as chamadas de segurança para o contexto do COM+ estejam disponíveis. Indica que a checagem do descritor de segurança do processo e a checagem de seguraça baseada em papéis serão executadas

 

Definimos também os níveis de autenticação para chamadas. Quando realizamos este tipo de autenticação, determinamos qual o grau de autenticação é executado quando as aplicações clientes chamam a aplicação COM+. O cuidado que devemos ter é de que, quanto mais elevado o nível de autenticação, maior a degradação da performance. A tabela abaixo apresenta os níveis existentes:

 

Nível de autenticação

Descrição

None

Nenhuma autenticação ocorre

Connect

Autentica as credenciais somente quando a conexão é realizada

Call

Autentica as credenciais no início de cada chamada realizada

Packet

Autentica as credenciais e verifica que todos os dados da chamada são recebidos. Esta é a configuração padrão para as aplicações COM+ Server

Packet Integrity

Autentica as credenciais e verifica se os dados na chamada foram modificados durante o trânsito

Packet Privacy

Autentica as credenciais e encripta o pacote, incluindo os dados e a identidade e assinatura do rementente

 

               Por fim, precisamos definir o nível de personificação da aplicação COM+. Esta configuração determina o grau de autoridade que a aplicação concede à outras aplicações que utilizam sua identidade quando realiza chamadas a ela. Esta configuração é válida somente para aplicações COM+ Server. A tabela abaixo apresenta os níveis existentes:

 

Nível de personificação

Descrição

Anonymous   

O cliente é anônimo para o servidor. O servidor pode personificar o cliente, porém o token de personificação criado não contém qualquer informação sobre o cliente

Identify   

O servidor pode obter a identidade do cliente e pode personificá-lo para realizar as checagens ACL  (Access Control List) necessárias

Impersonate   

O servidor pode personificar o cliente, enquanto agindo como seu representante, embora possua restrições. O servidor pode acessar recursos no mesmo computador do cliente. Se o servidor estiver no mesmo computador do cliente, ele pode acessar recursos de rede como o cliente. Se estiver com computadores diferentes, poderá acessar recursos que estiverem no mesmo computador do servidor. É a configuração padrão para as aplicações COM+ Server.

Delegate   

Assim como a configuração anterior, o servidor pode agir como representante do cliente, porém sem as mesmas restrições.

 

Destacamos apenas quatro serviços do conjunto total oferecido pelo COM+. Porém existem outros que podem contribuir de forma decisiva no design de sua aplicação. Faço um convite para que você visite o site do MSDN anteriormente referido e consulte todos os serviços disponíveis.

 

Criando um componente de serviços

Uma vez compreendido o que é o COM+, veja como utilizá-lo a partir dos sistemas desenvolvidos através da tecnologia .Net. Porém, tenha em mente dois aspectos importantes:

 

1.       O COM+ não foi projetado para uso com .NET e por isso, precisamos observar alguns detalhes durante a implementação das aplicações;

2.       Somente utilize o COM+ nas aplicações quando possuirem um escopo transacional distribuído, tanto em diferentes computadores quanto no uso de diferentes recursos, tais como servidores de bancos de dados, servidores de filas, entre outros.

 

Um componente de serviços (Serviced Components) é um componente desenvolvido através da tecnologia .Net que pode ser armazenado e gerenciado pelo COM+, fazendo assim uso de seus serviços. Para isto, a classe desenvolvida precisa implementar (herdar) a classe System.EnterpriseServices.ServicedComponent (veja a Listagem 1). Para que isso seja possível, adicione nas referências de seu projeto o componente System.EnterpriseServices, e importe (através da declaração Imports) o namespace de mesmo nome. Assim o componente já estará apto a utilizar os recursos do COM+.

Fazendo uma análise rápida no namespace System.EnterpriseServices, notaremos a grande quantidade de “classes atributos”, ou seja, classes onde seu uso ocorre através da inserção de atributos no código. Isso é um indicativo de que, a implementação dos serviços COM+ nas classes ocorre através da inserção de atributos na classe e métodos da mesma (veja na Listagem 1), a definição do tipo de transação a ser utilizado, através do atributo TransactionAttribute inserido no escopo da classe. Não entrarei em detalhe sobre a definição e uso de atributos, mas você poderá achar maiores detalhes no item “Extending Metadata using Attributes” do .Net Framework SDK (.Net Framework / Programming with the .Net Framework / Extending Metadata using Attributes).

Listagem 1: Definindo um componente de Serviços

'VB.Net
Imports
System.EnterpriseServices

_
Public Class
Credito
    Inherits
ServicedComponent

   'Adicione aqui o código da Classe

End Class

 

// C#

using System.EnterpriseServices;


[Transaction(TransactionOption.Required), JustInTimeActivation()]
public class Credito : ServicedComponent
{

    //Adicione aqui o código da classe
}

 

A Listagem 1 contém os atributos de classe TransactionAttribute, definindo o escopo transacional do componente e JustInTimeActivationAttribute, definindo a ativação e desativação do objeto, afim de informar ao COM+ que o objeto fará uso desses serviços. Praticamente todos os serviços do COM+ são definidos através de atributos de classe e são complementados com atributos definidos em métodos, como por exemplo, o atributo AutoCompleteAttribute, que permite ao método automaticamente executar o SetComplete num escopo transacional. O .Net Framework SDK possui a lista completa de todos os atributos disponíveis e seu respectivo escopo em .Net Framework / Reference / Class Library / System.EnterpriseServices. A dica é: saiba quais serviços serão necessários na sua aplicação, bem como informações adicionais ao COM+, e configure o atributo respectivo.

Mas “nem tudo são atributos”. Existe uma classe que é fundamental o conhecimento: ContextUtil. Esta classe fornece as informações a respeito do contexto do objeto dentro do COM+. Todos as propriedades e métodos são estáticos (Shared)  e nos retornam informações importantes sobre o contexto do objeto no COM+, como por exemplo, se o objeto encontra-se dentro de um contexto transacional ou ainda, permite votar numa transação, realizando o commit ou o abort dela.

 

Cuidados no desenvolvimento dos Componentes de Serviços

Quando desenvolvermos componentes de serviços onde este poderá ter como um cliente uma aplicação não-.Net (ou seja, COM), devemos tomar alguns cuidados especiais, afim de permitir a interoperabilidade:

·         Evitar utilizar construtores parametrizados

·         Evitar utilizar métodos estáticos (Shared em VB.Net)

·         Definir interfaces, como fonte dos eventos, para o código gerenciado

·         Inclua os HRESULTS nas exceções criadas por você

·         Forneça o GUID para os tipos

·         Conte com diferenças na herança

 

Como eu registro meu componente?

Uma vez que tenhamos desenvolvido o componente de serviços, o passo seguinte é instalá-lo no COM+. Essa instalação pode ser realizada de duas maneiras: manual e dinâmica. Porém, para que possamos realizar a instalação de um Component Services, temos que preencher alguns requisitos:

·   Strong name – um assembly que será registrado no COM+ precisa possuir um Strong name, que pode criado através do uso da ferramenta sn.exe.

·   Windows registry – o assembly precisa ser registrado no banco de dados do Windows, o Registry. Isto é necessário porque é lá que o COM+ armazena as configurações relativas as suas aplicações.

·   Type LibraryType library é um arquivo ou componente dentro de outro arquivo que contém as informações de tipo sobre os objetos expostos. Nos componentes de serviços, elas precisam ser registradas e instaladas dentro da aplicação COM+

·   Configurar serviços – após instalada a aplicação, os serviços adicionados programaticamente precisam ser çonfigurados no catálogo com COM+

 

Criando um Strong name

Strong name é um nome que consiste numa identidade do assemby, composta pelo nome, versão e cultura (se fornecido) do mesmo, reforçada pela adição de uma chave pública e uma assinatura digital gerada sobre o assembly. Através da utilização da ferramenta sn.exe, disponível no .Net Framework SDK, geramos um arquivo de extensão “.snk”, que é referenciado por um assembly. Para realizar esta atividade, siga os seguintes passos:

1.       Abra o Command Prompt (utilize o configurado juntamente com o Visual Studio .Net, que pode ser acessado em Iniciar / Programas / Microsoft Visual Studio .Net 2003 / Visual Studio .Net Tools / Visual Studio .Net 2003 Command Prompt);

2.       Para criar um arquivo chamado MSDNSample.snk, digite sn –k MSDNSample.snk e tecle Enter. O arquivo será gerado no diretório atual em que o sn.exe estiver sendo executado;

3.       Pronto, o arquivo .snk está gerado. No próximo passo, iremos referenciá-lo no nosso assembly;

4.       No projeto, abra o arquivo chamado AssemblyInfo, que é adicionado em todos os projetos criados. É neste arquivo que residem as informações do assembly, tais como Título, descrição, Copyright, GUID e versão, através de atributos inseridos no mesmo;

5.       Adicione o seguinte atributo: . Se necessário, informe juntamente com o nome do arquivo .snk a sua localização completa;

6.       Faça o build da sua aplicação.

 

O registro manual do Componente de serviços é realizado através do uso de outra ferramenta fornecida pelo .Net Framework SDK chamada .Net Framework Services Installation Tool – regsvcs.exe. Esta é outra ferramenta de linha de comando que realiza as seguintes ações:

·         Carrega e registra um assembly;

·         Gera, registra e instala uma Type Library dentro de uma aplicação COM+ 1.0 (a versão existente no Windows 2000. Windows XP e 2003 é a versão 1.5);

·         Configura os serviços adicionados programaticamente em nossas classes.

 

Como podemos notar, o regsvcs resolve-nos alguns dos requisitos, elencados anteriormente, para a instação de nosso componente de serviços. Para ser mais exato, só não resolve a questão da geração do strong name do nosso assembly. A instalação do componente de serviço pode ser realizado com o seguinte comando: regsvcs /appname:MSDNSample MSDNSample.dll, onde o appname é nome da aplicação COM+ onde desejamos instalar o componente e o MSDNSample.dll é o assembly, gerando ainda, adicionalmente o arquivo MSDNSample.tlb, que é a type library do componente de serviços. Maiores informações sobre o regsvcs.exe podem ser encontradas no .Net Framework SDK em .Net Framework / Tools and Debugger / .Net Framework Tools / .Net Framework Services Installation Tool (Regsvcs.exe). A grande vantagem do uso desta ferramenta é que você pode acompanhar todo o processo de registro do componente, podendo verificar possíveis erros.

O registro dinâmico do Componente de serviços é realizado, com uma simples cópia do assembly contento um ou mais componentes de serviço para o diretório Componentes da aplicação existente no COM+. Também é realizado através da simples chamada de um componente cliente, desde que este seja também desenvolvido com tecnologia .Net, onde na primeira chamada que for realizada, a CLR realiza todas as tarefas necessárias para o registro do Assembly, tal qual realizado pelo Regsvcs.exe, uma única vez para cada versão do mesmo.

Existe ainda alguns pontos adicionais que precisam ser observados com relação ao registro dinâmico. O primeiro ponto é que eles não são adicionados no GAC (Global Assembly Cache)  e, o segundo, é que não é válido para os casos onde seu componente de serviços seja invocado por objetos COM. Neste caso, o registro deve ser obrigatóriamente manual.

 

Conclusão

Neste artigo desvendei um pouco do que é o COM+, apresentando-o e descrevendo alguns de seus serviços. Procurei demostrar como implementar os Serviced Components, que são aplicações desenvolvidas com a tecnologia Microsoft .Net que utilizam os recursos disponibilizados pelo COM+.

É verdade que neste artigo não apresentei muito exemplos de código. Isto se deu porque o maior conhecimento que precisamos ter na criação dos Serviced Components está no COM+ e, foi neste ponto que procurei detalhar mais e é onde você deve focar seus estudos.