Caio Azevedo

Reporting Services - Artigos Publicados na Revista Codificando.NET

2011-07-14T05:09:00.000-07:00

Segue link das seis edições da revista Codificando .Net com meus artigos sobre Reporting Services.
Trata-se de um tutorial bem bacana sobre essa poderosa ferramenta, de sua arquitetura à codificação de relatórios.

http://www.codificandomagazine.com.br/revista/post/Edicao-11---N11.aspx
http://www.codificandomagazine.com.br/revista/post/Edicao-12---N12.aspx
http://www.codificandomagazine.com.br/revista/post/Edicao-13.aspx
http://www.codificandomagazine.com.br/revista/post/Edicao-14.aspx
http://www.codificandomagazine.com.br/revista/post/Edicao-15.aspx
http://www.codificandomagazine.com.br/revista/post/Edicao-16.aspx

Nota 1: Os artigos foram escritos e exemplificados na versão 2005 do Reporting Services, mas são perfeitamente aplicáveis para a versão 2008.

Nota 2: Se preferir os arquivos referentes as revistas estão em meu google docs disponíveis em :
http://bit.ly/p25IVH

Enjoy them..
Caio Azevedo

Caverna do Dragão = Escritório de TI

2011-07-12T06:48:00.000-07:00

Escritório = Caverna do Dragão: Quem trabalha em São Paulo sabe disso. O escritório geralmente fica num lugar longe pra caramba, cheio de perigos para chegar (Marginal Tietê, enchente, trânsito), onde você nunca sabe como chegou e tem que penar para sair.
Na verdade quando você entrou nele parecia um parque de diversão, mas na verdade é o lugar onde você vai passar por todo tipo de
perrengue antes de voltar pra casa!

Gerente de TI = Mestre dos Magos: Responsável por te colocar nas maiores enrascadas, sempre aparece do nada,
pergunta umas paradas nada a ver, não tem reposta para nenhuma de suas perguntas, nunca ajuda e por ele você não sai nunca da
Caverna do Dragão. Dizem que ele tem um poder e conhecimento ilimitado, mas você nunca vai ver em utilização. Se é que é verdade mesmo…

Suporte Técnico = Uni: Só faz volume no grupo, não tem nenhuma habilidade especial, não sabe falar (nem escrever),
precisa ser salva a toda hora colocando a equipe toda em perigo. Na verdade ninguém sabe porque ela está na party, e sempre tem um
que quer se sacrificar para ajudá-la. E no final, a party nunca vai embora sem a Uni!

Gerência de Projeto (PMO) = Vingador: Como se não bastasse o Mestre dos Magos para encher o saco, o
Vingador (que não tem nada a ver com você ou com seus problemas) vem toda hora te torrar a paciência, aumentando suas tarefas (ou enrascadas)
e tentando te aterrorizar com prazos e atividades que você não pode cumprir. Na verdade a função principal dele ninguém sabe direito,
mas é um dos seres mais temidos da Caverna do Dragão, que sempre aparece na hora errada e quando aparece você sabe que vem encrenca…

Equipe de Manutenção = Eric, Diana e Presto: Tem um que sempre quer se defender de
tudo quanto é bucha (com o escudo) e está sempre reclamando por isso, outro que é obrigado a fazer mágica para cumprir a demanda
(com o chapéu), e no final todo mundo acaba tendo que pular todos os processos (com o bastão) para o sistema voltar a funcionar….

Equipe Desenvolvimento = Hank, Sheila e Bobby: Sempre precisa conseguir fazer qualquer
coisa (arma, defesa, corda, rede, programa em três camadas) com apenas um arco e flecha e tem sempre um novato que vem e acaba quebrando
tudo o que funcionava perfeitamente (com o tacape). E a Sheila? Digamos que sempre tem um que desaparece quando mais se precisa…

Cliente = Tiamat: No fundo, só quer ter um pouco de sossego. É gigante e
poderoso. A Uni (suporte) acha que ele vai comê-la, por isso se caga de medo e perde a voz perto dele, o Vingador (PMO) que se acha o
maioral, também treme na base e acaba cedendo a tudo o que ele pede, o Mestre dos Magos (Gerente) não ajuda em nada mesmo, só fica
perguntando coisas sem sentido e some quando se precisa dele, e sempre sobra para a party (Manutenção e Desenvolvimento) se ferra para
vencê-lo a qualquer custo… E depois, com todo mundo cansado e sem paciência, o Mestre dos Magos e o Vingador voltam para trazer mais um
desafio antes de te deixar voltar para casa…

Cuidados ao selecionar as tecnologias de suas aplicações

2011-07-06T19:43:00.000-07:00

Em minhas recentes atividades como arquiteto de soluções Microsoft, deparei em alguns clientes com uma situação no mínimo inusitada. Todos tinham como meta construir suas aplicações seguindo as tecnologias do momento – Multicamadas, Web Services, Orientação a Objetos, etc. E eis que, como tantos outros, insidiam nos mesmos erros – talvez por falta de experiência, maturidade ou mesmo conhecimento, o certo é que, tentar de qualquer forma e a qualquer custo inserir todas, ou pelo menos boa parte dessas tecnologias em seus modelos de aplicação, é uma prática cada vez mais comum no ambiente corporativo, e as consequências podem ser desastrosas, pondo em risco todo o projeto. E ai já vi diversas situações, do uso excessivo e indiscriminado de uma tecnologia, à ilusão de se estar utilizado uma delas, a saber – Web Services e Orientação a Objetos respectivamente.

Problemas com modelos de aplicações não são novidades, desde os tempos da fórmula IIS * COM+ * SQL Server, a conhecida arquitetura Windows DNA – deparavamos com alguns cenários realmente assustadores, onde na maioria das vezes o grande problema era a utilização do mais velho ainda, paradigma Cliente – Servidor. A seguir temos alguns cenários que certamente estavam fadados ao fracasso:

01. Acesso aos dados [via ADO] diretamente nas páginas, e para piorar, sem preocupação com as propriedades de otimização dos objetos Connection, RecordSet e Command, transformando uma aplicação Web em um típico cliente / servidor com os cursores no servidor [um desastre total];

02. Sub utilização de componentes [Visual Basic 6.0], uma vez que nenhuma das features do COM+ [Pool de Ativação, Controle de Transações, Segurança, etc] eram utilizadas, lhes restando somente a tarefa de executar stored procedures, caracterizando mais um caso de desuso de tecnologia, ou pior a ilusão de um ambiente em 3 camadas, já que as regras de negócio, ou ao menos parte delas, estão em sua implementação.

Consequências

Não dá outra, clientes vendo seu investimento [tempo e dinheiro] indo para o espaço, todo seu planejamento comprometido porque “o sistema não funciona”, um verdadeiro fracasso. Tecnicamente temos alguns sintomas: (para os ambientes descritos)

- Sobrecarga de processamento – ora no IIS [via dllhost.exe], ora no COM+ [com altíssimos tempos de ativação dos componentes]

- Constantes “travamentos” da aplicação, e não menos comum de todas as demais aplicações do servidor.

- Conseqüentemente surge, como já cansei de ouvir – “soluções baseadas em COM+ não funcionam.

No “admirável mundo novo” do ambiente Microsoft .net, as aplicações podem ser modeladas das mais variadas maneiras, bem mais que no mundo DNA [o que sendo bem pessimista, só aumenta as chances de erros], sendo assim, uma boa dica para iniciar a modelagem de uma aplicação .net, seria delimitar todo o cenário, seus pré-requisitos técnico-operacionais, funcionalidades, infra-estrutura do ambiente de produção, políticas de contingência, dentre outras variáveis que certamente induzirão arquitetos, analistas, desenvolvedores, DBAs e a equipe de infra a cometerem erros que podem comprometer todo projeto, a seguir temos alguns casos, facilmente encontrados em qualquer ambiente corporativo.

Como já dissemos um erro comum no desenvolvimento de aplicações, é a ilusão de se utilizar uma tecnologia/paradigma quando na verdade se está bem longe disso. Já demonstramos um caso quando falamos do mundo DNA 3-tiers, quando apesar dos recursos, a equipe responsável continuava com o paradigma Cliente x Servidor 2-tiers. Nos dias de hoje, o que vemos são aplicações, ditas orientada a objetos com multicamadas, onde não temos qualquer construção com herança de objetos [por exemplo, na implementação de classes proprietárias para repositório de dados - pessoa, cliente, usuário] – um desperdício dos recursos e funcionalidades que a OO disponibiliza. Dentro desse cenário ainda encontramos uma “camada de apresentação” implementada de tal forma que detalhes do banco de dados [string de conexão, nome de tabelas, atributos, etc] precisam ser conhecidas. Ora, uma aplicação multicamadas tem, dentre seus atrativos, prover um considerável nível de abstração entre as camadas o que não é o caso. Assim, em um cenário com esses “detalhes de construção”, a aplicação aparentemente OO x Multicamadas, só não pode ser considerada Estruturada, pois a ferramenta de desenvolvimento não permite [qualquer assembly .net precisa de pelo menos uma classe].

Dentre as questões estruturais do desenvolvimento de softwares no nível arquitetural destacamos a escalabilidade [geralmente relacionada ao desempenho] – podendo ser do tipo horizontal ou vertical, e que varia basicamente em função do parque tecnológico disponível e das perspectivas de demanda para a aplicação. Imaginemos uma situação onde, a infra é definida com um pool de 4, 5 servidores potentes, configurados para implementar um Web Farm. Para que modelar uma solução distribuída, com Web Services, “desperdiçando” um ou vários desses servidores para “camada de regras de negócio”, sob o argumento que estamos diante de uma aplicação n-camadas ? Pois bem, estamos diante de um problema conceitual [sendo bem eufemista] – Aplicações multicamadas, não implicam necessariamente em aplicações distribuídas. Para piorar a situação desse cenário, a comunicação entre as “camadas” é feita com Web Services, um exemplo típico de modismo. Uma modelagem nessa forma tem um custo absurdo e não justificável.

A seguir tomaremos esse caso como exemplo, de qualquer forma, não seria mais interessante deixar todos os componentes de regras de negócio no modelo de deploy padrão .net, “folder” bin], assim faríamos melhor uso do ambiente descrito.

Para exemplicar essa terrível tendência, lançarei mão dos Web Services, uma poderosa tecnologia – eu diria que uma das mais importantes desde o advento da internet, no entanto seu uso sem critérios pode ser catastrófico [como no cenário acima]. Os Web Services, como toda grande idéia, prima pela simplicidade, permitindo que funcionalidades, até então restritas a um ambiente fechado [uma intranet por exemplo], estejam acessíveis para todos, em qualquer lugar, por diversos dispositivos e independente das plataformas envolvidas, sendo assim, se você resolver utilizá-los no seu modelo de aplicação antes de mais nada procure dentre esses três itens, uma justificativa para tal. Como nem tudo são flores, os Web Services tem seu custo, para realizar suas proezas ele se basea em três pilares – Serialização, XML e HTTP, o resto são conceitos e siglas, no fundo os Web Services são objetos serializados [Estruturas, DataSets, Arrays, Classes, etc], transmitidos entre as partes [através o já conhecido protocolo HTTP, livre dos firewalls], em um formato de dados que já se tornou padrão e amplamente difundido [viva o XML] e os custos ??? simples, o processo de serializar/deserializar tem seus custos de processamento [o menor de todos é bem verdade], a transmissão dos dados serializados via HTTP fatalmente acarreta um custo elevado, por concorrer com as requisições dos usuário POST/GET de páginas HTML e ASPX e principalmente pelo formato dos dados, XML, que contém um conjunto de metadados para compor as mensagens, tornando-as ainda maiores.

Sendo assim, aquele cenário “distribuído”, tendo Web Services como meio de comunicação está deveras comprometido. Uma alternativa para esse ambiente, distribuído e sobretudo interno, seria o uso de Remoting uma tecnologia, que atende a demanda [se considerarmos, a real necessidade de um ambiente distribuído], sem os custos dos web services. Essa proeza é possível pela substituição de tecnologia nos três pilares do Web Service:

- Serialização – No Remoting, em sua melhor configuração para performance, a serialização binária, ao invés da XML é a mais indicada, tornando os dados trafegados significativamente menores. [o remoting também suporta serialização XML]

- HTTP – Aqui substituímos o protocolo de transporte para TCP, em uma porta específica, o que por definição é mais eficaz que o HTTP, além de evitar a concorrência com as aplicações e suas páginas estáticas e dinâmicas.

Ao executarmos os dois cenários, percebemos através dos contadores utilizados, um sensível ganho de performance na versão Remoting, no entanto em um cenário real, onde nosso web service concorre com as demais aplicações web e sobretudo, onde o processamento do componente de negócio é considerável, essa diferença tende a aumentar, e outra, para que utilizar uma tecnologia, se temos alternativas mais elegante e performática ?? – modismo, hábito, facilidade na implementação ?, são nesses “detalhes” que distinguimos bons e maus projetos de software.

Pessoal, de maneira alguma sou contra o uso de Web Services, mas sua utilização em um ambiente intra-domínio, com dois ou mais servidores, trocando todo e qualquer tipo de mensagem – operações DML, pesquisas ao banco de dados para carregar controles, instância dos componentes de regras de negócio, entre outras, definitivamente não será bem sucedida quando a demanda atingir um patamar considerável.

Bom pessoal, eis um exemplo dentre tantos outros que encontramos em qualquer ambiente corporativo, muito cuidado com os modelos de aplicação utilizados em seus projetos, façamos uma reflexão no que já temos implementado, como poderíamos modificar, detectando pontos críticos e sugerindo mudanças em próximos projetos, o que não se podemos admitir é a incidência de erros dessa natureza passivamente.

Nota: Se alguém estiver interesado nos códigos utilizados na demonstração, sinta-se a vontade para entrar em contato.

Nota 2: Esse artigo foi originalmente publicado no site TIEspecialistas do qual sou colunista.

Ver: http://www.tiespecialistas.com.br/2011/06/cuidados-ao-selecionar-as-tecnologias-de-suas-aplicacoes/

Citações

2011-06-15T16:16:00.000-07:00

"A Utopia está lá no horizonte.

Me aproximo dois passos, ela se afasta dois passos.

Caminho dez passos e o horizonte corre dez passos.

Por mais que eu caminhe, jamais alcançarei.

Para que serve a Utopia?

Serve para isso: para que eu não deixe de caminhar".

(Eduardo Galeano)

"A Imaginação é mais importante que o conhecimento"

(Albert Einstein)

"A mentira é uma verdade que se esqueceu de acontecer"

(Mario Quintana)

Configurar HOTMAIL para Outlook 2007

2011-06-03T09:43:00.000-07:00

Parece piada, mas ralei um bocado para achar as informações necessárias para configurar minha conta hotmail no Outlook 2007 até que finalmente achei todas as informações necessárias que compilo aqui...

Abra o Outlook 2007 e em ferramentas, Clique em configurações de conta, na próxima janela e-mail clique em novo, na próxima aba marque (Microsoft Exchange, POP3,IMAP ou HTTP) e clique em avançar.

Próxima aba preencha com os dados (e-mail e senha) após preencher marque a opção (Definir manualmente as configuracoes do servidor ou tipo de servidores Adicionais) e clique em avançar.

Em informações de usuário:

Preencha com nome (teste)
e-mail (teste@hotmail.com)

Informações do servidor:

Tipo de conta deixe (POP3)
Servidor de entrada de e-mail Coloque (pop3.live.com)
Servidor de saida de e-mail (smtp) Coloque (smtp.live.com)

Informacoes de logon:

Nome de usuário (teste@hotmail.com)
Senha (senha do e-mail)

Clique agora em (Mais configurações)

(Em conta de e-mail) coloque seu nome de apresentação
(Em organização) coloque qualquer nome,
(Em e-mail de resposta) coloque seu e-mail do Hotmail,

Clique na aba (servidor de saída)

Marque a opção

(Meu servidor de saída (SMTP) requer autenticação)
na aba avançado marque a opção (este servidor requer uma conexão criptografada(SSL), na opção usar o sequinte tipo de conexão criptografado deixe em (Automatico)

É isso ai, espero que isso sirva para facilitar sua vida.

Caio Azevedo

AeroLixo de São Luis - MA

2011-04-16T15:04:00.001-07:00

Sinto-me muito a vontade para falar sobre isso por ser um ludovicense que viveu até os 23 anos na capital maranhense.

Moro ha pouco mais de 10 anos em São Paulo capital e nesses dias de debates absurdos sobre copa do mundo no BraZil e "problemas" com os aeroportos nas cidades sede, eis que volto à minha cidade natal para visitar minha sobrinha recém nascida e deparo com um aeroporto que prefiro chamar de aeroLixo. Isso mesmo amigos o aerolixo da terra do Sarney é uma vergonha nacional. Desembarquei durante a madrugada e eis que deparo com o fato de ter que andar da aeronave até a "área de desembarque" onde um pobre funcionário jogava as bagagens dos passageiros literalmente no grito, a "esteira das bagagens" é uma mesa coberta com uma lona imunda, o saguão de espera são tendas e banheiros químicos nojentos são usados pelos pobres coitados que aguardam seus amigos e entes queridos - o que inclui meus queridos pais.

Alguns dias depois, ao retornar deparo com uma área de embarque igualmente devastada, pobre das funcionárias, cujas expressões de desanimo resume tudo. Resumidamente trata-se de um mal cuidado galpão em condições precárias, o teto não demonstra qualquer segurança enfim, uma vergonha.

Não sei exatamente o que aconteceu, mas o que apurei com meus pais é que o saguão simplesmente desabou por falta de manutenção – desse que até onde eu saiba é um aeroporto internacional, enfim.

O certo é que essas foram as únicas fotos que fiz de uma cidade que um dia foi linda e um ponto turístico importante do nosso país, até porque nem isso ela é mais.

Segue link com as fotos que fiz e sintam-se a vontade para publicá-las, divulgá-las em vim, como diz o Marcelo D2 vamos fazer barulho.

Abraço..

Caio Azevedo

https://picasaweb.google.com/caio.aze/AeroLixoDeSaoLuis#

Solving VS2008 record bar issue during stress test application

2011-01-20T10:36:00.001-08:00

Hi everyone,

While I was trying to perform stress test into a web application with Visual Studio 2008, I faced an issue, whereby, the recorder bar does not appear when recording a new website.

My environment:
..:: VSTS 2008 : Win7 (64 bit) [I believe, Windows Vista, has the same problem] ::..

Fix:
..:: Win7 caches the list of explorer bars you have available and the recorder bar was not included in your list. ::..

The Solution:
Force Windows to rebuild that cache.
To do this, first make sure you have all Internet Explorer instances shut down,
then open the 32 bit registry editor and delete the following keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021493-0000-0000-C000-000000000046}
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021494-0000-0000-C000-000000000046}

The next time you boot Internet Explorer, your explorer bar cache will be rebuilt and the recorder bar should be available.

That's all folks..

Any commments, mail me at cazevedo@hotmail.com
see you next tip...

O cavaleiro das trevas - frases

2011-01-04T11:03:00.000-08:00

Esse 'feriadão' resolvi rever o Cavaleiro das Trevas pela n-éssima vez, além de ler A Piada Mortal, então resolvi coletar algumas frases do personagem principal das melhores fases do Batman.

I believe whatever doesn’t kill you simply makes you stranger.

Why so serious?

A little fight in you. I like that.

You let me know when you start taking things a bit more seriously.

Introduce a little anarchy!

This is what happens when an unstoppable force meets an immovable object.

I don’t wanna kill you. You complete me.

And I thought my jokes were bad…

I am an agent of chaos.

Madness is like gravity. All it takes is a little push.

Do I look like someone who has a plan?

The only sensible way to live in this world is without rules!

I’m not a monster. I’m just ahead of the curve.

I’m a dog chasing cars. I wouldn’t know what to do if I caught one.

If you’re good at something, never do it for free.

Alguém lembra de mais alguma ??? completa ai...

Explorando SQL Reporting Services 2005 Parte I

2010-08-23T15:44:00.001-07:00

Finalizada a publicação dos artigos sobre reporting services 2005 na revista da comunidade codificando .net (http://www.codificandomagazine.com.br/revista/), onde muita coisa é válida também para o 2008, iniciaremos a publicação aqui no blog, após um grande incentivo do nosso colega André Ferreira, bom vamos lá...

Olá pessoal, iniciamos aqui uma série de artigos onde faremos uma abordagem prática e teórica, dessa poderosa e pouco explorada que é o Reporting Services. Nesse primeiro momento veremos a versão do SQL 2005, por ainda ser a ferramenta padrão de banco de dados na maioria dos nossos clientes, mas em breve faremos uma explanação da versão 2008, bom divertimento.

PARTE 1 – INTRODUÇÃO AO REPORTING SERVICES
O Microsoft SQL Reporting Services, RS, é uma plataforma de relatórios completa. Parte integrante do framework de Business Intelligence baseada em serviços, ferramentas, APIs para desenvolvimento, publicação e gerenciamento dos relatórios, o RS foi inicialmente apresentando como um add-on do SQL Server 2000 no inicio de 2000. Atualmente, sua versão mais recente, é a do SQL 2008, mas aqui cobriremos aquela, parte integrante do SQL Server 2005, por ser a solução de banco de dados mais comumente utilizada.

Os relatórios do RS são baseados na linguagem RDL (Report Definition Language), que nada mais é que um dialeto XML criado pela Microsoft. E, uma vez que o ambiente do RS esta intimamente integrada à plataforma .net framework, suas ferramentas de desenvolvimento são os Visual Studio 2005 e 2008, ainda que o próprio SQL Server 2005 tenha um shell do Visual Studio 2005 chamado Business Intelligence Development Studio (BIDS).
Com o RS é possível criar soluções de relatórios como parte de uma aplicação, os chamados Local Mode, que são similares ao modelo utilizado no Cristal Reports ou Microsoft Access, além desse, temos o modelo de relatórios remoto que operam como uma aplicação web hospedados em um Web Application Server (IIS) e acessíveis via protocolo HTTP. Finalmente temos através da ferramenta Report Builder, uma forma de disponibilizar para os usuários criar seus próprios relatórios, atendendo assim ambientes corporativos, desenvolvedores, arquitetos e usuários.

Com o RS é possível criar soluções de relatórios como parte de uma aplicação, os chamados Local Mode, que são similares ao modelo utilizado no Cristal Reports ou Microsoft Access, além desse, temos o modelo de relatórios remoto que operam como uma aplicação web hospedados em um Web Application Server (IIS) e acessíveis via protocolo HTTP. Finalmente temos através da ferramenta Report Builder, uma forma de disponibilizar para os usuários criar seus próprios relatórios, atendendo assim ambientes corporativos, desenvolvedores, arquitetos e usuários.

Para qualquer solução de relatórios que faz uso do ambiente do RS faz-se uso dos elementos apresentados na figura abaixo, sendo que a interação entre esses elementos varia conforme o modelo do relatório, mas eles sempre estarão presentes, do processo de criação ao consumo pelo usuário final.

Figura 1.1 – Correlação entre elementos do Reporting Services

Na figura 1.1, temos o diagrama da relação entre os principais elementos de uma solução baseada em reporting services, relação que detalharemos a seguir:

RELATÓRIO
Correspondem ao front-end dos dados devidamente formatados e que correspondem a uma representação gráfica, funcional e operacional de um arquivo RDL, com características especificas conforme seu tipo. Os relatórios podem ser invocados por uma aplicação cliente, seja ele uma aplicação Windows, Web, por qualquer tecnologia que consuma WebService ou mesmo pelo ambiente do próprio report ing services.

APLICAÇÃO CLIENTE
São as aplicações capazes de implementar, gerenciar e visualizar os relatórios, sendo os principais, o Report Manager, o BIDS, Visual Studio,aplicações .net Windows e web por meio do controle ReportViewer, além do aplicativo Office-Model Report Builder.

ESTRUTURA DE DADOS VOLÁTIL

São as estruturas em memória que criamos para armazenar temporariamente o resultado das consultas que serão visualizadas nos relatórios, essas consultas são implementadas na forma de stored procedures, views, instruções T-SQL além de cubos OLAP.

DB ACCESS ENGINE

São os diversos mecanismos possíveis para acesso aos dados, corresponde às fontes de dados: de acesso ao SQL Server, Oracle, OLE DB, ODBC bem como Analysis Server Databases – OLAP.

REPOSITÓRIOS DE DADOS

São as fontes de dados das quais se extrai as informações para os relatórios criados e acessados via os DB Access Engines.

Novo Site da Treinando .net

2009-12-16T04:53:00.000-08:00

Olá Pessoal.. já está no ar o novo site da treinando .net, passem por lá e vejam os cursos que oferecemos. E já estou montando o material para o treinamento de reporting services 2008 para o ano que vem....

http://www.treinando.net

[]s,
Caio Azevedo.

Artigo Publicado na Codificando .net Magazine

2009-10-27T07:08:00.001-07:00

Pessoal,

Saiu mais uma edição da revista da comunidade codificando .net, a edição #12, onde, dentre outros assuntos interessantes, podemos conferir o segundo dos meus artigos sobre reporting services 2005.

A revista está disponível em : http://www.codificandomagazine.com.br/Revista/ e seu acesso é livre..

Boa Leitura.
Caio Azevedo

Problemas com Modelos de Aplicações Web

2009-10-24T07:12:00.000-07:00

Em minhas recentes atividades como arquiteto de soluções .net, deparei em alguns clientes com uma situação no mínimo inusitada. Todos tinham como meta construir suas aplicações seguindo as tecnologias do momento - multicamadas, web services, orientação a objetos, etc. E eis que, como tantos outros, insidiam nos mesmos erros - talvez por falta de experiência, maturidade ou mesmo conhecimento, o certo é que, tentar de qualquer forma e a qualquer custo inserir todas, ou pelo menos boa parte dessas tecnologias em seus modelos de aplicação, é uma prática cada vez mais comum no ambiente corporativo, e as consequencias podem ser desastrosas, pondo em risco todo o projeto. Deparei com diversas situações, de uso excessivo e indiscriminado de uma tecnologia, à ilusão de se estar utilizando uma delas, a saber - web services e orientação a objetos respectivamente.

Problemas com modelos de aplicações não são novidades, desde os tempos da fórmula IIS * COM+ * SQL Server, a conhecida arquitetura Windows DNA - deparamos com alguns cenários realmente assustadores, onde na maioria das vezes o grande problema era a utilização do mais velho ainda, paradigma Cliente - Servidor. A seguir temos alguns cenários que certamente estavam fadados ao fracasso :

01. Acesso aos dados [via ADO] diretamente nas páginas, e para piorar, sem preocupação com as propriedades de otimização dos objetos Connection, RecordSet e Command, transformando uma aplicação Web em um típico cliente / servidor com os cursores no servidor [um desastre total];

02. Sub utilização de componentes [Visual Basic 6.0], uma vez que nenhuma das features do COM+ [Pool de Ativação, Controle de Transações, Segurança, etc] eram utilizadas, lhes restando somente a tarefa de executar stored procedures, caracterizando mais um caso de desuso de tecnologia, ou pior a ilusão de um ambiente em 3 camadas, já que as regras de negócio, ou ao menos parte delas, estão em sua implementação.

Consequências

Não dá outra pessoal, clientes vendo seu investimento [tempo e dinheiro] indo para o espaço, todo seu planejamento comprometido porque "o sistema não funciona", um verdadeiro fracasso. Tecnicamente temos alguns sintomas: (para os ambientes descritos)

- Sobrecarga de processamento - ora no IIS [via dllhost.exe], ora no COM+ [com altíssimos tempos de ativação dos componentes]
- Constantes "travamentos" da aplicação, e não menos comum de todas as demais aplicações do servidor.
- Conseqüentemente surge como já cansei de ouvir - "soluções baseadas em COM+ não funcionam.

No "admirável mundo novo" do ambiente .net, as aplicações podem ser modeladas das mais variadas maneiras, bem mais que no mundo DNA [o que sendo bem pessimista, só aumenta as chances de erros], sendo assim, uma boa dica para iniciar a modelagem de uma aplicação .net, seria delimitar todo o cenário, seus pré-requisitos técnico-operacionais, funcionalidades, infra-estrutura do ambiente de produção, políticas de contingência, dentre outras variáveis que certamente induzirão arquitetos, analistas, desenvolvedores, DBAs e a equipe de infra a cometerem erros que podem comprometer todo projeto, a seguir temos alguns casos, facilmente encontrados em qualquer ambiente corporativo.

Como já dissemos, um erro comum no desenvolvimento de aplicações, é a ilusão de se utilizar uma tecnologia/paradigma quando na verdade se está bem longe disso. Já demonstramos um caso quando falamos do mundo DNA 3-tiers, quando apesar dos recursos, a equipe responsável continuava com o paradigma Cliente x Servidor 2-tiers. Nos dias de hoje, o que vemos são aplicações, ditas orientada à objetos com multicamadas, onde não temos qualquer construção com herança de objetos [por exemplo, na implementação de classes proprietárias para repositório de dados - pessoa, cliente, usuário] - um desperdício dos recursos e funcionalidades que a OO disponibiliza. Dentro desse cenário ainda encontramos uma "camada de apresentação" implementada de tal forma que detalhes do banco de dados [string de conexão, nome de tabelas, atributos, etc] precisam ser conhecidas. Ora, uma aplicação multicamadas tem, dentre seus atrativos, prover um considerável nível de abstração entre as camadas o que não é o caso. Assim, em um cenário com esses "detalhes de construção", a aplicação aparentemente OO x Multicamadas, só não pode ser considerada Estruturada, pois a ferramenta de desenvolvimento não permite [qualquer assembly .net precisa de pelo menos uma classe].

Dentre as questões estruturais do desenvolvimento de softwares no nível arquitetural destacamos a escalabilidade [geralmente relacionada ao desempenho] - podendo ser do tipo horizontal ou vertical, e que varia basicamente em função do parque tecnológico disponível e das perspectivas de demanda para a aplicação. Imaginemos uma situação onde, a infra é definida com um pool de 4, 5 servidores potentes, configurados para implementar um Web Farm. Para que modelar uma solução distribuída, com Web Services, "desperdisando" um ou vários desses servidores para "camada de regras de negócio", sob o argumento que estamos diante de uma aplicação n-camadas ? Pois bem, estamos diante de um problema conceitual [sendo bem eufemista] - Aplicações multicamadas, não implicam necessariamente em aplicações distribuídas. Para piorar a situação desse cenário, a comunicação entre as "camadas" é feita com Web Services, um exemplo típico de modismo. Uma modelagem nessa forma tem um custo absurdo e não justificável. A seguir tomaremos esse caso como exemplo, de qualquer forma, não seria mais interessante deixar todos os componentes de regras de negócio no modelo de deploy padrão .net, "folder" \bin], assim faríamos melhor uso do ambiente descrito.

Para exemplicar essa terrível tendência, lançarei mão dos Web Services, uma poderosa tecnologia - eu diria que uma das mais importantes desde o advento da internet, no entanto seu uso sem critérios pode ser catastrófico [como no cenário acima]. Os Web Services, como toda grande idéia, prima pela simplicidade, permitindo que funcionalidades, até então restritas à um ambiente fechado [uma intranet por exemplo], estejam acessíveis para todos, em qualquer lugar, por diversos dispositivos e independente das plataformas envolvidas, sendo assim, se você resolver utilizá-los no seu modelo de aplicação antes de mais nada procure dentre esses três itens, uma justificativa para tal. Como nem tudo na vida são flores, os Web Services tem seu custo, para realizar suas proezas ele se basea em três pilares - Serialização, XML e HTTP, o resto são conceitos e siglas, no fundo os Web Services são objetos serializados [Estruturas, DataSets, Arrays, Classes, etc], transmitidos entre as partes [através o já conhecido protocolo HTTP, livre dos firewalls], em um formato de dados que já se tornou padrão e amplamente difundido [viva o XML] e os custos ??? simples, o processo de serializar/deserializar tem seus custos de processamento [o menor de todos é bem verdade], a transmissão dos dados serializados via HTTP fatalmente acarreta um custo elevado, por concorrer com as requisições dos usuário POST/GET de páginas HTML e ASPX e principalmente pelo formato dos dados, XML, que contém um conjunto de metadados para compor as mensagens, tornando-as ainda maiores.

Sendo assim, aquele cenário "distribuído", tendo Web Services como meio de comunicação está deveras comprometido. Uma alternativa para esse ambiente, distribuído e sobretudo interno, seria o uso de Remoting uma tecnologia, que atende a demanda [se considerarmos, a real necessidade de um ambiente distribuído], sem os custos dos web services. Essa proeza é possível pela substituição de tecnologia nos três pilares do Web Service:

- Serialização - No Remoting, em sua melhor configuração para performance, a serialização binária, ao invés da XML é a mais indicada, tornando os dados trafegados significativamente menores. [o remoting também suporta serialização XML]
- HTTP - Aqui substituímos o protocolo de transporte para TCP, em uma porta específica, o que por definição é mais eficaz que o HTTP, além de evitar a concorrência com as aplicações e suas páginas estáticas e dinâmicas.

Pessoal, de maneira alguma sou contra o uso de Web Services, mas sua utilização em um ambiente intra-domínio, com dois ou mais servidores, trocando todo e qualquer tipo de mensagem - operações DML, pesquisas ao banco de dados para carregar controles, instância dos componentes de regras de negócio, entre outras, definitivamente não será bem sucedida quando a demanda atingir um patamar considerável.

A seguir, exemplificaremos dois cenários distribuídos, um como Web Services e outro com Remoting aplicável ao nosso ambiente, não entraremos em todos os detalhes da implementação dos modelos, nossa preocupação aqui é com a arquitetura [mas se precisar é só entrar em contato].

Cenário:

Temos um assembly, componente.dll, com a classe/método que precisamos acessar remotamente, esse método simplesmente executa uma instrução de repetição for 10000000 vezes sem qualquer operação por interação, para o acesso remoto, escreveremos uma "camada" web services e outra remoting que disponibilizarão o método para o cliente.

Figura 1 - Cenários de aplicação distribuída.

Modelo Web Services

Para implementação do modelo "Web Services", temos nosso componente, implementado como uma classe qualquer [código 1]. Agora precisamos de um "servidor" e assim teremos a combinação IIS [host] x Web Service [comunicação] - implementado em um arquivo .asmx [código 2] e hospedado em um diretório virtual como uma aplicação Web qualquer, que chamaremos WsRemote, [logo as mensagens trocadas concorrem com as demais aplicações]. Pronto, eis nossa porção "server" do ambiente distribuído desse cenário, onde toda complexidade [serialização, comunicação, listening], são resolvidos pelo IIS, com seu custo é claro.

Código 1 - Componente com "regra de negócio".

Atente para criação do objeto e chamada ao seu método.

Código 2 – Web Service.

Chamada ao componente --> método

Preparando Cliente:
Usaremos como cliente uma aplicação console [para simplificar]. Para tal precisamos do que chamamos Proxy do Web Service, que corresponde a uma classe também com os métodos disponíveis no Web Service [muita gente não sabe da existência dessa classe, já que o Visual Studio garante a "transparência"], essa classe é gerada pelo utilitário WSDL , com a seguinte sintaxe: WSDL http://localhost/WSRemote/WebService.asmx, em seguida é só compilar a classe e utilizar o assembly gerado no cliente [código 3].

Código 3 – Cliente Web Service [referência à dll proxy].

Modelo Remoting

Esse modelo é um pouco mais complicado, afinal não temos o IIS para as funcionalidades mais complexas, por isso construiremos o nosso [ou pelo menos uma ferramenta similar e que atenda as funcionalidades que precisaremos].
O princípio aqui é a ativação do objeto [marshal], onde o cliente tem uma referência do objeto remoto - no entanto, ele efetivamente é criado no servidor [código 4]. Agora precisamos do "servidor" [um elemento em estado de espera, que atenda as requisições dos clientes remotos] - e ai construiremos aquele que corresponde ao IIS [host] do cenário anterior. Nosso remoting server, é um programa executável como outro qualquer que disponibiliza um canal (endereço IP : Porta), além é claro, o nosso componente [código 5].

Preparando Server:
Para disponibilizar nosso componente basta compilá-lo, copiar a dll gerada para mesma pasta do servidor [remoteService.exe] e executá-lo - não esqueça de fazer referência à dll na compilação do servidor.

Código 5 – Remoting Server.

Remote Server - mantém estado de espera - listening

Preparando Cliente:
Novamente nosso cliente é uma aplicação console. Para testá-lo copie o componente para o local do cliente [isso é necessário para referenciar o componente remoto] e o execute [código 6]. Atente que apesar da dll está fisicamente localizada no client sua ativação é realizada no server [comprovado pela execução do construtor do componente informando o número de instâncias].

Código 6 – Remoting Client.

Implementação do cliente - modelo remoting

Ao executarmos os dois cenários, percebemos através dos contadores utilizados, um sensível ganho de performance na versão Remoting, no entanto em um cenário real, onde nosso web service concorre com as demais aplicações web e sobretudo, onde o processamento do componente de negócio é considerável, essa diferença tende a aumentar, e outra, para que utilizar uma tecnologia, se temos alternativas mais elegante e performática ?? - modismo, hábito, facilidade na implementação ?, são nesses "detalhes" que distinguimos bons e maus projetos de software.
Bom pessoal, eis um exemplo dentre tantos outros que encontramos em qualquer ambiente corporativo, muito cuidado com os modelos de aplicação utilizados em seus projetos, façamos uma reflexão no que já temos implementado, como poderíamos modificar, detectando pontos críticos e sugerindo mudanças em próximos projetos, o que não se podemos admitir é a incidência de erros dessa natureza pacivamente.

E para finalizar, segue os códigos exemplo utilizados em nosso artigo, como dito, minha maior preocupação é com as questões relacionadas à arquitetura, por isso não atentamos para detalhes da codificação, mas com certeza seu entendimento ajuda bastante, de qualquer forma sintam-se à vontade para qualquer esclarecimento/crítica/sugestão. Projeto WSxRemote - download
Até a próxima !!
Caio Azevêdo

Por Dentro do IL

2009-07-29T11:27:00.000-07:00

Prefácio:

Nossa proposta nesse espaço inicialmente seria de analisarmos a linguagem C#, sua sintaxe, implementações dos conceitos de orientação a objetos, etc. Para tal acredito que a implementação de programas console [aqueles que rodam no DOS], seja a melhor alternativa nesse primeiro momento, sem dúvida o Visual Studio é uma ferramenta poderosíssima, mas tentaremos não fazer uso do mesmo, para uma maior intimidade com a linguagem, o compilador, suas ferramentas e as diversas técnicas de desenvolvimento que o ambiente nos permite. Uma ressalva ao editor de programas, onde o Visual Studio tem uma interface bastante agradável (destaque para identação e visual das linhas de código), no entanto para os mais nostálgicos o uso do Edit é bem vindo.

Pré-requisitos:

Para execução de um programa .net o mínimo necessário é a instalação do Framework, disponível para download no site da Microsoft [http://msdn.microsoft.com/netframework/technologyinfo/howtoget/default.aspx]. Uma vez instalado temos disponíveis os compiladores VB e C#, para nosso caso o programa csc [digite csc /? para maiores detalhes de compilação]. Caso tenhamos apenas o framework instalado seria interessante adicionar à variável de ambiente Path, o caminho do programa csc, se tivermos o Visual Studio instalado utilize a opção Visual Studio Command Prompt, dentre as ferramentas do VS.

Finalmente:

Bom pessoal, nada mais batido como primeira lição nos escritos de qualquer linguagem de programação que o conhecido “Hello Word”, pois bem, não faremos diferente, no entanto, utilizaremos desse programa para passarmos algumas informações importantes para o entendimento de qualquer programa C#. Faremos uma viagem pelo universo do MSIL, a mágica da Microsoft para que os programas sejam multiplataformas, independente de linguagem, seguros, versionados, etc. O MSIL, nada mais é que uma linguagem intermediaria gerada no processo de compilação do código fonte, assim ao final desse processo temos um código intermediário e dependente do runtime do Framework ao invés dos executáveis “independentes”, até então gerado pelos compiladores [e ainda possível nos compiladores C++, e C# em situações especiais]. Esse código é formado por um conjunto de instruções em linguagem intermediária e por metadados, conhecido como MANIFESTO, onde temos descrito informações essenciais para execução do código, tais como definição de tipos, controle de versão [e ai o fim da terrível DLL HELL, ou incompatibilidade de versões], referencia à assemblies externos, dentre outras funcionalidades.

Esse formato do código, com dados e metadados, permite aos assemblies uma autodescrição o que dispensa a necessidade das antigas Type Libraries ou IDLs. Assim o próprio runtime do framework, localiza e obtém as informações necessárias para executar as instruções conforme preciso, tudo junto num mesmo lugar.

O processo de execução inicia-se com o runtime do Framework [o conhecido CLR], que carrega do código IL e o executa, como já dissemos, o código tem é gerenciado e seguro. No entanto, antes dessa execução o CLR, garante a validade do código para só então compilá-lo, gerando um código de fato executável compatível com o processador, através do just-in-time compiler [JITter] que é cacheado, e caso haja alteração no código fonte / IL o mesmo é atualizado. Durante a execução do código gerenciado, o mesmo recebe serviços como garbage collection [responsável pela uma “limpeza” periódica na memória], interoperabilidade com códigos não gerenciados, serviço de controle de versão, segurança, etc, ou seja nosso processo fica constantemente monitorando para garantir sua qualidade em performance, segurança, gerenciamento otimizado da memória e outras funcionalidades providas pelo Framework.

A seguir, analisaremos nosso programa, o compilaremos e analisaremos seu código intermediário.

using System; //Referenciando namespace System
namespace Imasters //Definindo namespace Imasters
{
class hello //Definindo classe hello
{
public static void Main() //Função principal
{
for(int i=0;i<5;i++)

Console.WriteLine("\tBem-Vindo à coluna - C# e Tecnologias .NET!!!");
}

}

Nada mais simples, um programa que exibe uma mensagem cinco vezes. Utilizando o velho notepad, salvemos um arquivo hello.cs. e vamos para o processo de compilação:

Compilando:
csc hello.cs [Será gerado um “executável”, hello.exe.]

Bom, como já dissemos, o código aparentemente é como outro qualquer, no entanto podemos visualizar seu IL através do utilitário ILDASM, executado a partir do diretório onde temos nosso executável. Ildasm hello.exe

Figura 1
Aqui temos claramente as seções do nosso código, acima o manifesto, com os metadados do programa, em seguida temos o namespace [veremos em artigos posteriores] Imasters, a classe hello e abaixo as subseções, com o construtor da classe e o método principal, Main.

Figura 2

Na figura 2 temos os metadados dos nossos aplicativo.

Na linha, .assembly extern mscorlib, temos uma referencia ao assembly externo, no caso, o mscorlib [mscoree.dll, usado pelo sistema operacional para carregar o executável “intermediário”]. O compilador insere alguns parâmetros para identificação e segurança como, por exemplo, .publickeytoken, que é a identificação básica do assembly e .ver que corresponde à versão do mesmo.
Em seguida temos a seção .assembly, com seus parâmetros .hash, utilizado para garantir que o assembly referenciado não tenha sido modificado e .ver que representa a versão do nosso código, aqui não especificado, nas opções de compilação.

Finalmente temos a seção .module que identifica nosso assembly [hello.exe], aqui temos um MVID, que o identifica, e é regerado a cada compilação, informações de identificação e localização do arquivo físico.

Figura 3

Aqui já vemos nossos primeiros códigos MSIL, estamos diante do construtor de nossa classe, que a principio é executado para cada classe, podendo ou não ser modificado [maiores detalhes em artigos posteriores], interessante ressaltarmos a primeira linha, onde o atributo cil managed, o define como código gerenciável. As linhas IL_9999: são identificadores de instruções assembly, onde a primeira utiliza o opcode ldarg que carrega um argumento para pilha de execução, 0, indica o operador this, ou seja a própria classe, em seguida é feito uma chamada ao método System.Object e assim o controle é retornado ao método que o chamou.

Figura 4
Finalmente chegamos em nosso código propriamente dito. Mais uma vez vemos que o método é gerenciado pelo atributo cil managed. Aqui destaque para algumas diretivas: .entrypoint, que especifica Main como ponto de entrada do programa. A diretiva .maxstack que especifica o tamanho máximo na pilha para o método. Em seguida temos os códigos com as instruções do programa, destaque para ldstr que carrega uma string na pilha de execução, br.s, que desvia a seqüência de execução e blt.s, que desvia seqüência condicionalmente, call que faz uma chamada ao método estático System.ConsoleWriteLine e por fim o retorno ao método que iniciou o processo [no caso _CorExeMain da mscoree.dll].

É isso ai pessoal, temos uma referencia enorme de opcodes IL, que na verdade dificilmente precisaremos manipular [não que seja impossível], ainda assim acho válido entendermos o funcionamento dos nossos assemblies, e o interessante é que tudo no .NET funciona assim, seja uma o code-behind de uma página ASPX, um WebService, uma DLL no COM+, um aplicativo console, qualquer coisa [opa, menos os programas não gerenciados, que com ojá dissemos, podem ser codificados em C++, ou mesmo no nosso C#].

Segue um guia de referencia interessante sobre o conjunto de instruções MSIL.

Ate a próxima,
Caio Azevedo.

Apresentação

2009-02-07T05:59:00.000-08:00

Olá Pessoal.... após resistir por muito e muito tempo, finalmente sucumbi ao mundo dos blogs.
Meu principal objetivo é trocar informações sobre tecnologia, especialmente Microsoft.