Mais uma dica simples, utilizando um recurso adicionado no .NET 4.0, para saber se o Sistema Operacional é 64 bits, ou o processo que está executando nossa lógica é 64 bits temos jeitos simples para fazer isso.

Para descobrir se o sistema operacional é 64 bits é só fazer:

Environment.Is64BitOperatingSystem

E para saber se o processo é 64 bits:

Environment.Is64BitProcess

Ambas as propriedades retornam um booleano.

Por enquanto é isso.

Abraços.

Trabalho criando ferramentas e frameworks pra outros desenvolvedores, e nem sempre quando disponibilizamos alguma API para utilização, podemos sair removendo métodos por exemplo, não sabemos quem utilizou, e se em alguma possível atualização o software vai parar de funcionar ou não, e o atributo Obsolete pode nos ajudar nesse cenário, informando o que está obsoleto na API e será descartado em breve, ou simplesmente recomendando uma alternativa melhor!

A utilização do atributo é simples, vou pegar o código do BasicIoC e criar um método obsoleto de propósito, só preciso informar a mensagem que será mostrada para quem for utilizar o método.

[Obsolete("This method is obsolete; use method Register instead.")]
public Container Map<T>()
{
    _baseType = typeof (T);
    return this;
}

E o interessante é que o Intellisense já ajuda o desenvolvedor mostrando que o método é obsoleto.

Isso não impede a utilização do método, mas mostra avisos quando compilamos que utilizamos um método obsoleto.

Mas podemos adicionar um segundo parâmetra booleano quando configuramos o atributo, forçando um erro de compilação caso existe algum código utilizando um método ou classe obsoleta.

[Obsolete("This method is obsolete; use method Register instead.", true)]
public Container Map<T>()
{
    _baseType = typeof (T);
    return this;
}

Agora o código não compila mais, no lugar de um aviso um erro de compilação é mostrado, mostrando que estamos utilizando um método obsoleto.

Por hoje é isso.

Até o próximo post.

A idéia é simples, .times vai executar o códido o número de vezes informado, upto vai executar o código o número de vezes incrementando do valor inicial até o final, e downto vai executar o código o número de vezes decrementando do valor inicial até o final.

Veja o código:

[sourcecode language="ruby"]
puts "testando times"
2.times {|i| print i, " "}
puts
puts "testando upto"
1.upto(5) {|i| print i, " "}
puts
puts "testando downto"
10.downto(5) {|i| print i, " "}
[/sourcecode]

Resultado:

Simples e interessante, no C# não temos nada disso, mas podemos criar algo parecido utilizando um pouco de Métodos de Extensão, não vou explicar nesse post o que são e como criar as extensões, vejam no post linkado.

Segue os códigos das Extensões e do aplicativo de teste:

[sourcecode language="csharp"]
public static class Extensions
{
public static void Times(this int value, Action<int> action)
{
for (int i = 0; i < value; i++)
{
action(i);
}
}

public static IEnumerable<int> UpTo(this int start, int end)
{
for (int i = start; i <= end; i++)
{
yield return i;
}
}

public static IEnumerable<int> DownTo(this int start, int end)
{
for (int i = start; i >= end; i–)
{
yield return i;
}
}

public static void Each<T>(this IEnumerable<T> enumerable, Action<T> action)
{
foreach (var value in enumerable)
{
action(value);
}
}
}

class Program
{
static void Main(string[] args)
{
Console.WriteLine("testando times");
3.Times(x => Console.Write("{0} ", x));
Console.WriteLine();
Console.WriteLine("testando upto");
5.UpTo(10).Each(x => Console.Write("{0} ", x));
Console.WriteLine();
Console.WriteLine("testando downto");
10.DownTo(5).Each(x => Console.Write("{0} ", x));

Console.ReadLine();
}
}
[/sourcecode]

E o resultado:

Bom é isso, o código é simples mas foi divertido e gostei do resultado final, apesar de achar que em Ruby fica muito melhor gostei do resultado final em C#, e para quem não conhece Ruby recomendo estudar, não precisa trabalhar com Ruby, mas é muito interessante conhecer novas tecnologias, mais sobre o que penso sobre isso nesse post..

Por enquanto é só, código no GitHub.

Abraços.

Ano novo, nova atenção para o blog, depois de um ano complicado com trabalho novo, casa nova, cidade nova, o blog ficou meio abandonado, mas agora tudo está tranquilo e pretendo postar com mais frequência!

Para quem não acompanhou as outras publicações segue os links.

• Mensageria o Início
• Frameworks para Mensageria
• Compilando o MassTransit
• Request-Reply com MassTransit

Eu inverti um pouco a ordem dos posts, deveria ter começado com os conceitos do MassTransit, mas após esse post vou começar a postar os conceitos, estou traduzindo a documentação para pt-br também, isso vai ajudar os interessados, e vale lembrar que o projeto é Open Source e está no GitHub, então quem quiser ajudar toda ajuda é bem vinda, é só fazer um fork lá no MassTransit e começar a programar :).

Então voltando a falar dos Enterprise Integration Patterns, hoje vou mostrar como construir o patter Publish-Subscribe utilizando o MassTransit.

Explicando de uma forma simples, teremos alguém que publica algum tipo de mensagem, e um ou mais interessados podem se inscrever para receber as mensagens publicadas, cada consumidor inscrito vai receber uma cópia da mensagem publicada.

Pensando em um cenário mais interessante, imagine um sistema que consulta preços de viagens, esse sistema poderia publicar uma mensagem perguntando o valor de uma viagem qualquer, do outro lado vários consumidores um para cada operadora receberia uma cópia da mensagem e faria suas consultas, podendo ainda retornar uma mensagem para quem publicou com as informações solicitadas. E nenhum desses sistemas se conhecem, o único ponto em comum é o contrato ou seja as mensagens trocadas que cada um tem interesse.

Bom vamos para o exemplo.

O primeiro projeto que temos é o projeto com as mensagens, nesse exemplo tanto o Publisher quanto o Subscriber estão interessados em algum tipo de mensagem, então quando o Subscriber receber uma mensagem de interesse dele, vai responder outra que será de interesse do Publisher.

Segue as mensagens, que são POCO´s normais.

[sourcecode language="csharp"]
public class SampleRequest
{
public SampleRequest()
{
CorrelationId = Guid.NewGuid();
}

public Guid CorrelationId { get; private set; }
public string Message { get; set; }
}

public class SampleResponse
{
public Guid CorrelationId { get; set; }
public string Subscriber { get; set; }
public string Message { get; set; }
}
[/sourcecode]

Agora com as mensagens criadas vou criar um Console App para ser um Publisher, o código é simples então vou mostrar todo o código e as explicações vem depois, e o código dos Subscribers são parecidos.

[sourcecode language="csharp"]
class Program
{
static void Main(string[] args)
{
Bus.Initialize(bus =>
{
bus.UseMsmq();
bus.ReceiveFrom(
"msmq://localhost/publisher");
bus.UseMulticastSubscriptionClient();
});

new Service().Start(Bus.Instance);

Console.ReadLine();
}

}

public class Service : Consumes.All
{
private IServiceBus _serviceBus;
private UnsubscribeAction _unsubscribeToken;

public void Dispose()
{
_serviceBus.Dispose();
}

public void Start(IServiceBus serviceBus)
{
_serviceBus = serviceBus;
_unsubscribeToken = _serviceBus.SubscribeInstance(this);

while (true)
{
Console.WriteLine("Escreva uma mensagem: ");
var message = Console.ReadLine();
if (message == "exit")
break;

var sampleMessage = new SampleRequest
{
Message = message
};
_serviceBus.Publish(sampleMessage);
}
}

public void Stop()
{
_unsubscribeToken();
}

public void Consume(SampleResponse message)
{
Console.WriteLine("Resposta do da mensagem com ID {0} recebida:", message.CorrelationId);
Console.WriteLine("Quem respondeu: {0}", message.Subscriber);
Console.WriteLine("Mensagem de resposta: {0}", message.Message);
}
}
[/sourcecode]

A primeira parte do configuramos o MassTransit, onde informo que vou utilizar o MSMQ bus.UseMsmq(), lembrando que com o MassTransit também temos a opção de utilizar o RabbitMQ, além de implementar outros transportes para outras ferramentas.

O segundo passo é a configuração de qual fila do MSMQ o publisher vai receber as mensagens de interesse dele bus.ReceiveFrom(), e o terceiro passo é utilizar Multicast Subscription, isso não é tão simples para explicar aqui mas vai ter um post só sobre isso, mas é assim que internamente por troca de mensagens o MassTransit fica sabendo quem tem interesse em que tipo de mensagem quando ele está funcionando.

E por último instancio a classe Service chamando o método Start passando a instância do ServiceBus.

A classe Service é mais interessante, ela implementa a Interface Consumes<T>.All do MassTransit, aqui eu estou falando que o Publisher está interessado em consumir todas as mensagens to dipo SampleResponse. O MassTransit disponibiliza outras Interfaces para consumo de mensagens, onde temos mais poder para decidir que tipo de mensagem ou se podemos ou não consumir uma mensagem, mas fica para depois isso tudo :).

Detalhe para o método Consume que deve ser implementado por causa da Interface, é ali que será recebido por parâmetro o tipo da mensagem de interesse, no método mostro alguns detalhes de quem enviou a mensagem, e no método Start tenho uma lógica simples para ficar sempre perguntando uma mensagem no Console, além do método _serviceBus.Publish() que vai fazer todo o trabalho de pegar a classe, serializar, enviar para o MSMQ e distribuir para as filas dos Subscribers interessados.

O código dos Subscribers é bem parecido, com a diferença do método Consume deles que além de consumir a mensagem, publica uma mensagem de retorno que é de interesse do Publisher. Segue o código de um dos Subscribers.

[sourcecode language="csharp"]
class Program
{
static void Main(string[] args)
{

Bus.Initialize(bus =>
{
bus.UseMsmq();
bus.ReceiveFrom(
"msmq://localhost/firstsubscriber");
bus.UseMulticastSubscriptionClient();
});

new Service().Start(Bus.Instance);

Console.ReadLine();
}

}

public class Service : Consumes.All
{
private IServiceBus _serviceBus;
private UnsubscribeAction _unsubscribeToken;

public Service()
{

}

public void Dispose()
{
_serviceBus.Dispose();
}

public void Start(IServiceBus serviceBus)
{
_serviceBus = serviceBus;
_unsubscribeToken = _serviceBus.SubscribeInstance(this);
}

public void Stop()
{
_unsubscribeToken();
}

public void Consume(SampleRequest message)
{
Console.WriteLine("Mensagem com ID {0} recebida.", message.CorrelationId);
Console.WriteLine("Enviando resposta…");
var sampleResponse = new SampleResponse
{
CorrelationId= message.CorrelationId,
Subscriber = "First Subscriber",
Message =
string.Format(
"Resposta da mensagem {0}",
message.CorrelationId)
};
_serviceBus.Publish(sampleResponse);
Console.WriteLine("Resposta enviada!");
}
}
[/sourcecode]

É importante lembrar que cada Subscriber tem sua própria fila. Agora uma imagem do funcionamento do envio e recebimento das mensagens.

Bom por hoje é só, o código fonte está no GitHub.

Abraços.

São apenas curiosidades, não acredito que esses valores vão dizer que uma linguagem é melhor que outra, mas os resultados são curiosos.

Primeiro vamos as configurações de Hardware dos meus testes:

HP Pavilion dv4-1150br (uma droga de notebook)

•  Core2Duo T5800 2Ghz
• 3GB de memória DDR2
• HD de 5400 RPM

E estou utilizando Windows 7 x64.

O código em C# é o mesmo utilizado pelo Ayende, só alterei a classe que será criada n vezes, e converti o código para Java, falando nisso qualquer absurdo escrito em Java por favor avisem, não é meu forte :).

Primeiro vamos as classes que serão criadas em C# e Java.

C#

[sourcecode language="csharp"]
public class Album
{
public string Nome { get; set; }
public int NumeroDeMusicas { get; set; }
public DateTime DataDeLancamento { get; set; }
}
[/sourcecode]

Java

[sourcecode language="java"]
public class Album{
private String _nome;
private int _numeroDeMusicas;
private Date _dataDeLancamento;

public String getNome(){
return _nome;
}

public void setNome(String nome){
_nome = nome;
}

public int getNumeroDeMusicas(){
return _numeroDeMusicas;
}

public void setNumeroDeMusicas(int numeroDeMusicas){
_numeroDeMusicas = numeroDeMusicas;
}

public Date getDataDeLancamento(){
return _dataDeLancamento;
}

public void setDataDeLancamento(Date dataDeLancamento){
_dataDeLancamento = dataDeLancamento;
}
}
[/sourcecode]

O código para testar é simples, durante 1 segundo n instâncias da classe Album serão criadas, códigos de teste.

C#

[sourcecode language="csharp"]
class Program
{
static void Main(string[] args)
{
var cronometro = Stopwatch.StartNew();

var total = 0;

while (cronometro.ElapsedMilliseconds < 1000)
{
Album album = new Album();
total++;
}

cronometro.Stop();
Console.WriteLine(total);
}
}
[/sourcecode]

Java

[sourcecode language="java"]
public class JavaTeste {

public static void main(String[] args) {
long time = System.currentTimeMillis();
long endTime = time + 1000;

int total = 0;

while(System.currentTimeMillis() < endTime){
Album album = new Album();
total++;
}

System.out.println(total);
}
}
[/sourcecode]

E os resultados…

C#: 629475
Java:  41518639

Resumindo, o Java criou o infinito e além mais objetos que o C#,  ahh então Java é mais rápido? Depende, foi só um teste de um cara curioso :)

Abaixo imagens dos testes.

Abraços.

Update 01

Confesso que fiquei impressionado com o resultado, e resolvi verificar o teste novamente, e valeu pela idéia também Alexandre Tarifa :), o vilão da história é o Stopwatch, modifiquei o teste em C# para não utilizar o Stopwatch, e sim o Enviromenti.TickCount.

Segue o código:

[sourcecode language="csharp"]
static void Main(string[] args)
{
var final = Environment.TickCount + 1000;

var total = 0;

while (Environment.TickCount < final)
{
Album album = new Album();
total++;
}

Console.WriteLine(total);
}
[/sourcecode]

O resultados mudam para cada execução, na última ficaram assim, bem melhor:

C#: 40166858
Java:  42875611

Segue imagem do teste em C#:

Estou curioso para ver esse teste em outras linguagens, se a fadiga deixar faço mais testes :).

Abraços

Dependendo da forma de comercialização do software, é interessante permitir somente uma instância da aplicação rodando no computador, é fácil fazer isso utilizando a classe Mutex.

Abaixo o código da valiação em uma aplicação WinForms, mas a lógica é a mesma para todas as aplicações.
[sourcecode language="csharp"] namespace Mutex
{
static class Program
{
[STAThread]
static void Main()
{
bool criarNovaAplicacao;
using (System.Threading.Mutex mutex = new System.Threading.Mutex(true, “AplicacaoDeTeste”, out criarNovaAplicacao))
{
if(criarNovaAplicacao)
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
}
}
}
}[/sourcecode]
Até o próximo post.

Existem ótimos frameworks de mapeamento objeto relacional, no mundo .Net o mais famoso é o NHibernate, seguido de perto, ou não :), pelo Entity Framework, cada um com suas vantagens e desvantagens que não cabe especificar nesse artigo.

Agora vamos pensar em um mundo onde não quero ficar mapeando tabela com classe, mas também não quero ficar escrevendo códigos e mais códigos usando ADO.NET puro, é ai que o Simple.Data faz o seu trabalho, e faz muito bem!

O Simple.Data é um projeto OpenSource e está disponível no GitHub, e foi inspirado no ActiveRecord e DataMapper do Ruby, e atualmente possui providers para os seguintes bancos de dados:

• SQL Server 2005 ou superior
• SQL Server Compact Edition 4.0
• Oracle
• MySQL 4.0 ou superior
• SQLite
• MongoDB

Na documentação do projeto, estão informando que o suporte a PostgreSQL e Azure Table Storage está em progresso, então em breve mais novidades serão disponibilizadas!

Nesse artigo, estou utilizando o SQL Compact, e o Simple.Data está disponível para instalação pelo Nuget, o comando para instalação da versão para SQL Compact.

Install-Package Simple.Data.SqlCompact40

Antes de começar a mostrar os códigos, vale citar que o Simple.Data utiliza os recursos de linguagem dinâmica do C#, ou seja a keywork dynamic é utilizada o tempo todo, quando definimos uma conexão com o banco de dados o objeto de retorno já é um dynamic.

Não pretendo explicar dynamic aqui nesse post, para entender mais sobre o assunto eu recomendo o blog do Elemar Jr.

Vamos para o primeiro código, onde estabelecemos a conexão com o banco de dados, lembrando que esse é o formato para SQL CE.

private static dynamic _db;

static void Main(string[] args)
{
    _db = Database.OpenFile("SimpleData.sdf");
    Console.Read();
}

Já que _db é um objeto dinâmico, não temos intellisense para nos ajudar com os objetos do banco de dados, e não existe verificações na hora da compilação :), se der algum problema só vamos descobrir com o software funcionando, mas nada que inviabilize a utilização de objetos dinâmicos ;).

Quando estamos trabalhando com o Simple.Data, não é obrigatório a utilização de POCO´s, ou seja não preciso ter uma classe que representa um tabela, eu faço isso por costume e por facilidades na hora de programar, então eu criei uma classe EstiloMusical que representa minha tabela.

public class EstiloMusical
{
    public int IdEstiloMusical { get; set; }
    public string Nome { get; set; }
}

Então no Simple.Data temos duas opções para as operações básicas, ou seja o famoso CRUD, ou trabalhamos com objetos, nossos POCO´s, ou com parâmetros nomeados.

Toda a geração de SQL é feita pelo Simple.Data, então temos que informar corretamente o nome das tabelas ou campos nas operações, segue dois exemplos de inclusão de dados, a primeira utilizando POCO e a segunda utilizando os parâmetros nomeados.

var estiloMusical = new EstiloMusical
    {
        Nome = "Death Metal"
    };

_db.EstiloMusical.Insert(estiloMusical);

_db.EstiloMusical.Insert(Nome: "Jazz");

Quando precisamos alterar um registro, também temos a opção de fazer utilizando POCO ou os parâmetros nomeados, e ai entra algo muito interessante do Simple.Data, vamos montar o nome do método passando o campo chave que deverá ser utilizado, no caso da minha tabela o nome do campo chave é IdEstiloMusical então o método chamado será UpdateByIdEstiloMusical, segue os códigos:

var estiloMusical = new EstiloMusical
    {
        IdEstiloMusical = 2,
        Nome = "Blues"
    };

_db.EstiloMusical.UpdateByIdEstiloMusical(estiloMusical);

_db.EstiloMusical.UpdateByIdEstiloMusical(IdEstiloMusical: 1, Nome: "Black Metal");

Não vou mostrar toda a API do Simple.Data aqui já que ela é simples e possui uma documentação simples de entender, apesar de tomar alguns cuidados com o dynamic já que não teremos nunhuma checagem em tempo de compilação, o Simple.Data é uma ótima alternativa para acesso a dados, não notei problemas de desempenho, vou criar alguns testes de desempenho depois coloco aqui o resultado.

A solução apresentada aqui está no Github.

Por hoje é isso!

Abraços.

Porém, antes de continuar, recomendo a leitura dos 3 primeiros artigos que escrevi sobre mensageria.
Agora vou direto para a prática, assim ficará mais fácil definir e mostrar alguns conceitos.

• Mensageria o Início
• Frameworks para Mensageria
• Compilando o MassTransit

Nos exemplos vou utilizar o framework MassTransit, e o MSMQ da Microsoft, já que é gratuito e está disponível no Windows. É só habilitar nos recursos do Windows.

O nome do padrão é auto explicativo, teremos uma aplicação que envia uma mensagem, e aguarda uma mensagem de retorno,  é por isso que utilizamos o MSMQ ou no caso do MassTransit temos também a opção de utilizar o RabbitMQ. Mas vamos com calma, vamos entender nossas mensagens.

No exemplo teremos duas mensagens RequisitarCalculoSalario e RespostaCalculoSalario, as mensagens não serão utilizadas para trafegar dados. Vou utilizá-las apenas para passar o identificador do funcionário que desejo saber o salário.  Então podemos falar que nossas mensagens seriam POCO´s simples, ou melhor o contrato que uma aplicação conhece, não importa quem solitica ou quem responde a mensagem, o que importa é receber a mensagem que estou interessado. Segue a implementação das mensagens.

public class SolicitarCalculoSalario : CorrelatedBy<Guid>
{
    public Guid CorrelationId { get; set; }
    public int IdFuncionario { get; set; }

    public SolicitarCalculoSalario()
    {
        CorrelationId = Guid.NewGuid();
    }
}

public class RespostaCalculoSalario : CorrelatedBy
{
    public Guid CorrelationId { get; set; }
    public decimal Salario { get; set; }
}

O primeiro ponto que precisamos entender sobre o MassTransit, é que as mensagens devem implementar a Interface CorrelatedBy<TKey>, o CorrelationId pode ser entendido como um identificador entre as transações, e pensando em larga escala, é recomendado utilizar Guid para a implementação.

Então atenção para a primeira regra, toda mensagem utilizando o MassTransit deve implementar a Interface CorrelatedBy<TKey>.

Com as mensagens criadas, o próximo passo é implementar o Requester, nesse exemplo será um ConsoleApp. Um detalhe é que ao criar um projeto com .NET 4.0, o target framework nas configurações do projeto por padrão assume o valor .Net Framework 4 Client Profile, com o Client Profile o projeto não vai compilar, então é necessário alterar para .Net Framework 4, lembrando que o MassTransit também gera as .dlls para .Net 3.5.

Abaixo o código está separado em 3 partes: a configuração do ServiceBus, a publicação da requisição e o código completo do funcionamento do Requester.

Bus.Initialize(sbc =>
   {
        sbc.UseMsmq();
        sbc.VerifyMsmqConfiguration();
        sbc.UseMulticastSubscriptionClient();
        sbc.ReceiveFrom("msmq://localhost/requester");
    });

Bus.Instance.PublishRequest(
    new SolicitarCalculoSalario { IdFuncionario = idFuncionario },
    callBack =>
        {
            callBack.Handle<RespostaCalculoSalario>(message =>
                {
                    Console.WriteLine("Resposta da Mensagem {0} recebida", message.CorrelationId);
                    Console.WriteLine("Salario: {0}", message.Salario);
                });
             callBack.SetTimeout(10.Seconds());
         });

static void Main(string[] args)
{
    Bus.Initialize(sbc =>
        {
            sbc.UseMsmq();
            sbc.VerifyMsmqConfiguration();
            sbc.UseMulticastSubscriptionClient();
            sbc.ReceiveFrom("msmq://localhost/requester");
        });

    Console.WriteLine("Informe o ID do funcionário para calcular o salário:");
    var idFuncionario = 0;
    int.TryParse(Console.ReadLine(), out idFuncionario);

    while (idFuncionario != -1)
    {
        Bus.Instance.PublishRequest(
            new SolicitarCalculoSalario { IdFuncionario = idFuncionario },
                callBack =>
                {
                    callBack.Handle<RespostaCalculoSalario>(message =>
                        {
                            Console.WriteLine("Resposta da Mensagem {0} recebida", message.CorrelationId);
                            Console.WriteLine("Salario: {0}", message.Salario);
                        });
                    callBack.SetTimeout(10.Seconds());
                });

                int.TryParse(Console.ReadLine(), out idFuncionario);
     }
}

Agora uma explicação detalhada sobre a configuração do ServiceBus.

•  sbc.UseMsmq(): A primeira escolha que precisamos fazer qual “transporte” vamos utilizar para as mensagens, assim nós configuramos que estamos utilizando o MSMQ.
• sbc.VerifyMsmqConfiguration(): Já que estamos utilizando o MSMQ, com esse método validamos se a instalação do MSMQ está correta.
• sbc.UseMulticastSubscriptionClient(): Aqui nós estamos habilitando a possibilidade do Bus “conversar” com outras instâncias de ServiceBus na rede, com isso não precisamos ter um ponto central de controle das instâncias existentes.
• sbc.ReceiveFrom(“msmq://localhost/requester”): Configuração de a fila que o Requester vai receber as mensagens, o interessante é que se a fila não está criada ainda, o MassTransit faz todo o processo de criação da fila.

Outras opções são disponibilizadas na configuração do ServiceBus, mas para o exemplo de hoje está bom!

Depois que configuramos o ServiceBus, vamos publicar uma mensagem, no caso será publicada uma mensagem do tipo SolicitarCalculoSalario, passando o Id do Funcionário, para isso utilizamos o método PublishRequest.

No primeiro parâmetro do PublishRequest informamos a mensagem que vamos publicar, e no segundo parâmetro informamos o callBack, um detalhe para a configuração do callBack é para o método Handle<>, aqui estamos falando que o Requester está esperando mensagens do tipo RespostaCalculoSalario de retorno, e quando uma dessas mensagens for recebida temos a lógica de escrever na tela as informações da mensagem.

Logo após o método Handle<> precisamos definir um Timeout para o callBack, ou seja a thread que publicou a solicitação ficará bloqueada até receber a mensagem de retorno, ou até acabar o tempo configurado no timeout, se o tempo acabar uma Exception é disparada, vale ressaltar que não precisamos bloquear a thread, temos recursos de async no .Net que podemos utilizar, mas isso fica para outro artigo.

No código acima veja a aba Requester para ver toda a lógica do programa.

Agora que as mensagens e o Requester estão prontos, vamos ao código do Responser, o código é muito parecido com  o do Requester, então segue o código completo, logo abaixo tem a explicação dos detalhes diferentes.

static void Main(string[] args)
{
    Bus.Initialize(sbc =>
        {
            sbc.UseMsmq();
            sbc.VerifyMsmqConfiguration();
            sbc.UseMulticastSubscriptionClient();
            sbc.ReceiveFrom("msmq://localhost/responser");
            sbc.Subscribe(subs => subs.Handler<SolicitarCalculoSalario>(
                msg =>
                {
                    Console.WriteLine("Solicitação {0} recebida, iniciando calculo do funcionário {1}",
                                       msg.CorrelationId, msg.IdFuncionario);

                    var resposta = new RespostaCalculoSalario
                        {
                            CorrelationId = msg.CorrelationId,
                            Salario = (decimal) (msg.IdFuncionario*DateTime.Now.Millisecond * 3.14)
                        };

                        Console.WriteLine("Enviando resposta");
                        Bus.Instance.MessageContext().Respond(resposta);
                 }));
            });

        Console.WriteLine("Aguardando mensagens");
        Console.Read();
    }

A principal diferença do Responser é que é utilizado o método Subscribe do ServiceBus para inscrever o Responser para receber mensagens do tipo SolicitarCalculoSalario, quando uma mensagem chega, é criada uma mensagem do tipo RespostaCalculoSalario, e é definido o CorrelationId da nova mensagem igual o da mensagem recebida, e ai faço uma lógica qualquer para descobrir o salário do Funcionário.

Feito isso através do método MessageContext() do ServiceBus, eu consigo informações sobre quem fez a requisição, e envio uma mensagem de resposta utilizando o método Respond().

Abaixo uma imagem dos programas funcionando e conversando utilizando as mensages.

O assunto não é dos mais simples, mas é muito interessante. Entre os benefícios posso destacar alto desacoplamento, a possibilidade de distribuir processamento, alta escalabilidade, esses itens vamos ver com mais detalhes quando implementarmos o exemplo de Grid/Distributor, mas ai já é avançar muito por enquanto!

Pegue o código fonte no Github e boa diversão!

Abraços.

O primeiro passo para criar o nosso repositório de pacotes, é criar um WebApplication vazio, lembre-se de criar vazio, porque vamos utilizar o NuGet para criar o servidor :), e ele vai tentar escrever uma Default.aspx, e não precisamos de toda aquela estrutura padrão de um site criado pelo VS.NET.

Feito isso, vamos ter o enorme trabalho instalar um pacote do NuGet, que prepara o site para ser o servidor de pacotes :D, então na janela de gerenciamento do NuGet vamos escrever Install-Package NuGet.Server, feito isso todas as referências necessárias serão adicionadas ao projeto, e uma estrutura de pasta será criada dentro do projeto.

Feito isso, é só adicionar o site ao IIS, e o servidor estará pronto. Na pasta Packages do site, nós vamos jogar os pacotes disponíveis no nosso servidor, sempre que quiser disponibilizar um novo pacote, ou atualizar é só jogar o arquivo .nupkg nessa pasta.

Ao acessar o site criado vemos uma página inicial, que mostra qual é URL onde listaremos os pacotes disponíveis. Na segunda imagem abaixo, já está mostrando o pacote do BasicIoC que adicionei no servidor.

Agora o próximo passo é adicionar o link do nosso servidor nas configurações do NuGet, na janela de opções do Visual Studio.

Agora na janela do NuGet no Visual Studio, podemos escolher em qual servidor vamos utilizar, podemos escolher todos, ou um dos cadastrados, depois listo os pacotes instalados no servidor e é listado o BasicIoC, e já consigo instalar o BasicIoC no projeto.

Bom de uma forma simples, podemos criar um repositório de frameworks, em grandes empresas é comum existir frameworks corporativos (assunto bem explorado pelo pessoal do VoidPodCast), e o NuGet é a melhor escolha para criar esse repositório.

Abraços e até o próximo post.

Ano passado eu fiz alguns testes, utilizando alguns gráficos em Silverlight, e utilizei a Conjectura de Collatz para a geração dos gráficos, segue a definição da conjectura de Collatz que está na Wikipedia.

Eu realmente achei interessante, no final do post terá um gráfico em Silverlight onde poderá informar um número e ver que sempre chegará a 1 mesmo, independente do número informado. Fiz o código o mais simples possível, até porque o problema é simples de resolver, segue os códigos em C#, Python e Ruby.

class Program
{
    static void Main(string[] args)
    {
        Collatz(50);
        Console.Read();
    }

    static void Collatz(int numero)
    {
        Console.WriteLine(numero);

        if(numero == 1)
            return;

        if(numero % 2 == 0)
            Collatz(numero / 2);
        else
            Collatz(3 * numero + 1);
    }
}

def collatz(numero):
    print(numero)
    if numero == 1:
        return
    if numero % 2 == 0:
        collatz(numero / 2)
    else:
        collatz(3 * numero + 1)

collatz(50)

def collatz(numero)
  puts numero

  if numero == 1
    return
  end

  if numero % 2 == 0
    collatz(numero / 2)
  else
    collatz(3 * numero + 1)
  end
end

collatz(50)

Já que disse anteriormente, o algoritmo é simples, em todas as linguages utilizei um método recursivo, e mesmo sem experiência em Ruby ou Python da para entender o que o código faz, então não explicarei detalhes do código, mas confesso que Python tem me agradado muito!

Agora para quem quiser testar a Conjectura de Collatz, abaixo tem o gráfico em Silverlight, só escolher um número e clicar no botão Collatz, o número 50 fica legal, não geram muitos resultados e fica legal analisar o gráfico, já que o mesmo é pequeno!

O código fonte do projeto está no GitHub.

Abraços e até o próximo artigo.