Image Image Image Image Image
Scroll to Top

Topo

web

27

abr
2012

Sem Comentários

Em .NET
Blog
REST

Por Allison

Desenvolvimento de Web APIs evolui no ASP.NET MVC 4

Em 27, abr 2012 | Sem Comentários | Em .NET, Blog, REST | Por Allison

Fonte: Elemar Jr./InfoQ

A nova versão do framework para desenvolvimento de aplicativos Web da Microsoft, o ASP.NET MVC 4, amplia muito o suporte ao desenvolvimento de aplicações Web API. O framework, agora integralmente open source e disponível no Codeplex, possibilita o desenvolvimento de serviços RESTful com pouco esforço.

Entre as novidades na versão 4, destacam-se a facilidade para criar rotas para recursos (evitando colisão com rotas padrões MVC), a escrita de Actions para cada um dos métodos HTTP, o suporte nativo ao fornecimento de objetos em formato JSON e XML, além do suporte ampliado a URLs de consulta compatíveis com OData.

O ASP.NET MVC Web API permite um novo modelo de desenvolvimento web, em que o servidor provê apenas conteúdo e a geração da apresentação ocorre inteiramente no browser. Ou seja, no lugar de prover o HTML pronto, o servidor pode entregar um composto HTML + JavaScript, deixando que os dados sejam requisitados conforme demanda, via Ajax, para um serviço RESTful. (Importante destacar que o template padrão para aplicações ASP.NET MVC já possui referências para JQuery.) A possibilidade de gerar, automaticamente, respostas em formato JSON facilita consideravelmente a manipulação de código JavaScript.

As novas funcionalidades já são suportadas tanto no novo Visual Studio 11 (ainda beta e disponível para download na versão Ultimate), quanto no Visual Studio 2010 (mediante instalação).

Conforme noticiamos aqui, embora o ASP.NET MVC 4 não esteja completo, a Microsoft já recomenda sua utilização em produção. A Microsoft disponibilizou um mini-tutorial sobre o framework, com artigos e vídeos.

Tags | , , , , , , ,

12

abr
2012

Sem Comentários

Em Blog

Por Allison

Como melhorar o Carregamento da página do meu blog?

Em 12, abr 2012 | Sem Comentários | Em Blog | Por Allison

Fonte: CriarSites

Este é um guest post escrito por Kênyo Carvalho do blog Vetores Download.

Nos dias de hoje a internet está em quase todos os lugares do mundo, desde sua implantação de forma comercial a qualidade do serviço melhorou a cada dia e hoje em muitos lugares não se tem problema em visitar por exemplo um site cheio de cores que à tempos atrás passava-se minutos para abrir, mas ainda em muitos lugares que o desenvolvimento da tecnologia encontra-se atrasada os internautas sofrem com o problema e você que é blogueiro como eu e o Celso Lemes, precisam dar um pouco de sua atenção para esses usuários.

O carregamento de uma página é tão importante para o usuário que visita seu site ou blog quanto para seu próprio projeto, hoje por exemplo os motores de busca aponta o carregamento rápido de uma página da web como um critério positivo para sua colocação nas pesquisas, além disso tenha certeza que se tiver um layout atraente e um bom conteúdo e o critério citado anteriormente você irá conseguir mais visitantes fiéis.

Para melhorarmos esse ponto tão importante que muitos deixam passar despercebido precisamos reavaliar totalmente nosso blog ou site, mas não é difícil, basta analisarmos o que é importante e o que não é para os nossos visitantes, como por exemplo;

O que é desnecessário nas páginas do meu blog?

Muita propaganda sem relevância, Widgets desnecessários como os calendários e hora, imagens em tamanhos de arquivos acima de 1 MB, e principalmente uma página com grande extensão (muitos artigos no caso de um blog).

O que é necessário na página do meu blog?

Primeiramente foque conteúdo, quando alguém visita seu site é porque ele procura determinada coisa, então ofereça primeiro o que ele procura, links interligando palavras chaves de um artigo para o outro, propaganda relevante para o usuário e em pouca quantidade, imagens compactadas em formato .JPG, .PNG.

A resposta para essas duas perguntas feitas acima irão variar certamente de projeto para projeto, no caso de um blog que trabalha apenas com imagens certamente deixará sua página bem mais colorida do que um blog que aborda assuntos direcionado por exemplo como criar um site.

Não deixe seu blog com cara de circo organize, junte tudo que for desnecessário e de um “Ctrl – ALT – DEL”, disponibilize poucos artigos na sua página inicial e procure usar os links internos para dar mais versatilidade ao acesso, renove a cara do seu projeto, os visitantes irão agradecer ao terem um impacto visual mais agradável, simples e com o que ele procura e com um melhor, dando um melhor desempenho na velocidade de seu acesso.

Tags | , , ,

A arquitetura do SpiderDuck em detalhes: o novo serviço de processamento de links do Twitter

Em 21, dez 2011 | Sem Comentários | Em Arquitetura, Blog, Redes Sociais | Por Allison

O SpiderDuck, é um novo serviço do Twitter para gerenciar e otimizar o processamento em tempo real de URLs inseridos em tweets. Foi projetado com 6 componentes principais, distribuindo a responsabilidade de consultar, processar e armazenar as informações das URLs. A arquitetura do sistema tem o foco em reduzir o tempo de resposta e a latência do tráfego de dados, além de permitir o aumento em escala conforme o crescimento da demanda.

Links em tweets devem ser processados pelo Twitter quanto ao tipo e a relevância do conteúdo referenciado. Caso a URL aponte para uma foto ou vídeo, por exemplo os aplicativos do lado do cliente (web, mobile etc.) precisam apresentar a mídia correspondente junto ao texto do tweet. Os links também são processados pelo módulo de segurança, que verifica a presença de malware no endereço referenciado, entre outras coisas, e os “Tweet Buttons” contabilizam o número de compartilhamentos de cada link.

Antes do SpiderDuck o Twitter usava um serviço mais simples para análise de URLs compartilhadas, fazendo requisições via HEAD e eventuais redirecionamentos. Mas essa solução apresentava algumas limitações:

O serviço resolvia o endereçamento da URL, mas não realizava o download do conteúdo. As informações sobre a resolução da URL não eram persistidas em disco, permanecendo apenas em memória, no cache. Caso uma instância do cache ficasse fora do ar, os dados seriam perdidos.

O serviço também não leva em conta regras para bots modernos, como limitação da taxa de transferência; também não seguia diretivas do controlador de buscas de robots (robots.txt).

O time de engenheiros do Twitter chegou à conclusão que seria necessário desenvolver um serviço mais sofisticado para processamento de URLs, que atendesse à necessidade da empresa no longo prazo:

Nossa primeira ideia foi construir o sistema em cima de um crawler existente, que fosse open source. Mas percebemos que todos os crawlers disponíveis possuem duas características de que não precisávamos: os crawlers realizam a leitura de URLs de forma recursiva o que aumenta sua complexidade; além disso, são otimizados para a leitura em grande escala, e precisávamos de algo mais leve, capaz de fazer a leitura de URLs em tempo real. Decidimos então criar um novo sistema que atendesse às necessidades específicas do Twitter.

O SpiderDuck utiliza algumas soluções open source já adotadas em outros serviços do Twitter, como o agregador de conteúdo Scribe; o Finagle, um protocolo RPC criado para realizar o tráfego intenso de dados; e o Twitter Commons, um conjunto de bibliotecas que opera sobre a JVM.

Arquitetura

A arquitetura do SpiderDuck é modular (veja a figura), o que contribui para a escalabilidade do serviço.

Componentes do SpiderDuck (fonte: Twitter)

O SpiderDuck é composto por seis módulos principais:

  • Kestrel. Sistema de mensageria utilizado no Twitter para enfileiramento dos tweets mais recentes. O Kestrel é o ponto de partida do SpiderDuck, assim que recebe um tweet contendo uma URL, solicita a busca das informações dessa URL para outro módulo, o Scheduler.
  • Schedulers. Determinam se a busca do conteúdo da URL deve ser agendada ou não, e caso necessário faz o redirecionamento da URL. Esse módulo realiza o parse e o download do conteúdo, extrai os metadados e armazena toda essa informação em duas estruturas de armazenamento do sistema, o Metadata Store e o Content Store. Cada schedule trabalha de forma independente, permitindo que novos schedulers sejam adicionados, favorecendo a escalabilidade horizontal do sistema.
  • Fetchers. Componente que realiza a requisição HTTP em busca do conteúdo da URL. São implementados com servidores Thrift, com inteligência para tratar os limites de taxa de transferência e reconhecer as diretivas do controlador de buscas via bots, resolvendo umas das principais limitações da solução anteriormente usada.
  • Memcached. Um cache distribuído utilizado pelo Fetcher para armazenar temporariamente as informações dos arquivos robots.txt.
  • Metadata Store. Distribuição customizada do Cassandra que permite armazenar informações sobre a resolução e os metadados da URL. Essas informações são mantidas em uma tabela de hash, utilizando a URL como chave. O repositório é utilizado pelos aplicativos cliente do Twitter, para consumir informações da URL em tempo real.
  • Content Store. Um cluster com Hadoop Distributed File System (HDFS), um sistema para replicação de dados distribuídos extremamente rápido, que formam o repositório com o conteúdo de todas as URLs processadas.

Performance

A separação entre o Schedulers e os Fetchers permite que múltiplos tweets com a mesma URL sejam processados somente uma vez. Isso reduz a latência e aumenta a velocidade no processamento. Veja o que dizem sobre isso os engenheiros do projeto:

O SpiderDuck processa centenas de URLs a cada segundo, e o Metadata Store trata perto de 10 mil requisições por segundo. Normalmente cada requisição é realizada para uma URL especifica, sendo possível uma requisição para um lote de até 300 URLs ao mesmo tempo.

Para processar uma nova URL, que ainda não foi armazenada pelo SpiderDuck, partindo da criação do tweet e indo até a requisição externa e o armazenamento dos dados, o sistema gasta em média cinco segundos de processamento. A maior parte desse tempo é consumida no Fetcher, no momento em que o sistema extrai as informações da URL em um site externo.

Quando um novo tweet menciona uma URL que foi armazenada pelo SpiderDuck, o tempo para processar as informações da URL se reduz para dois segundos em média. Ou seja, uma aplicação cliente do Twitter tem de esperar por dois segundos para obter todas as informações da URL. E boa parte das 10 mil requisições por segundo recebidas pelo Metadata Store trata de consultas que em média, levam de quatro a cinco milissegundos de processamento.

Integração

Os serviços do Twitter consomem dados do SpiderDuck de várias maneiras; a mais frequente é a busca de informações complementares (metadados e resolução) da URL no Metadata Store. Outros serviços acessam os logs do SpiderDuck no HDFS para agregar informações utilizadas pelos sistemas de analise e métricas internas, o dashboard do Twitter.

No SpiderDuck serviços não solicitam o processamento de uma URL. O próprio sistema resolve e processa o conteúdo das URLs de tweets recentes. Após processar as URLs o sistema disponibiliza as informações para consumo dos serviços.

Conclusões


Uma forma efetiva para gerenciar URLs é apenas um dos desafios da do Twitter, que vem fazendo muanças constantes em arquitetura e tecnologias (como já reportamos aqui). Através do blog de engenharia do Twitter e da conta @twittereng, os engenheiros do Twitter compartilham um pouco sobre esses desafios, apresentando informações e estratégias relacionadas a arquitetura do serviço.

Fonte: Eder Magalhães/InfoQ

Tags | , , , , , , ,

23

nov
2011

Sem Comentários

Em Blog
JSON

Por Allison

JSON + Spring

Em 23, nov 2011 | Sem Comentários | Em Blog, JSON | Por Allison

É possível trabalhar com JSON e Spring. Você pode produzir dados em formato JSON dos controllers do framework, facilitando a manipulação da informação na página.

Mas como fazer isso?

Para isso, utilizamos a lib json-lib-ext-spring. Existem outras alternativas (biblioteca/lib), mas particularmente achei esse mais fácil e menos trabalhosa. Não esqueça de fazer o download da Json-lib e suas dependências.

Após o donwload e adição no buildPath do projeto, apenas é preciso fazer algumas pequenas modificações:

A primeira é acrescentar um arquivo chamado views.xml ao diretório do WEB-INF com o seguinte conteúdo:

O segundo é adicionar o conteúdo seguinte ao arquivo de configuração do Spring:

Lembre-se de setar uma ordem se você estiver utilizando algum outro view resolver.

Com essas alterações efetuadas, basta utilizar “jsonView” como o viewname e o model será convertido para json quando voltar para o cliente:

Fonte: Loiane Groner

Tags | , , ,

23

nov
2011

Sem Comentários

Em Blog

Por Allison

Google anuncia nova ferramenta para criar apresentações

Em 23, nov 2011 | Sem Comentários | Em Blog | Por Allison

Novidades no Google Docs. A gigante da web apresentou nessa terça-feira (18) uma nova versão da ferramenta para criar apresentações no melhor estilo PowerPoint, sem ser necessário sair do navegador. Utilizando recursos do HTML5, finalmente os usuários têm uma maneira mais completa de criar slideshows sem recorrer ao concorrente da Microsoft ou ao Keynote da Apple.

Numa primeira olhada, o internauta percebe que o visual da ferramenta de apresentações do Docs segue o padrão estabelecido dos outros produtos do Google. No entanto, ficou mais limpo e agradável de usar. Fora o visual, o Google aposta principalmente na colaboração como recurso matador da ferramenta.

Assim como acontece na criação de textos e planilhas, os usuários podem trabalhar numa mesma apresentação simultaneamente, realizando alterações e adicionando novos itens. Cada internauta ganha um marcador individual baseado em cores para determinar que, naquele momento, ele está mexendo em certo trecho do documento.

Transições e animações compõem a ferramenta renovada. Dá para definir animações específicas para cada item adicionado ao slideshow, inclusive as formas criadas a partir do recurso de desenho livre. O mesmo vale para as transições entre slides, que seguem as diretrizes definidas pelo HTML5.

Justamente por depender do HTML5, a ferramenta de apresentações mostrada hoje só funciona em navegadores mais modernos. Se for o Chrome, criação do Google para concorrer com Firefox, Opera e outros browsers, – a compatibilidade é garantida.

Os usuários vão perceber um aviso informando sobre a nova versão da ferramenta na próxima vez que entrarem no Docs. Basta confirmar que querem ver as novidades para terem a ferramenta devidamente habilitada.

Originalmente publicado em The Official Google Blog

Fonte: TechTudo

Tags | , , , , ,

20

nov
2011

Sem Comentários

Em Blog

Por Allison

Closure Stylesheets do Google facilita a manipulação de código CSS extenso

Em 20, nov 2011 | Sem Comentários | Em Blog | Por Allison

O Google liberou como open source sob a Licença Apache 2.0, o projeto Closure Stylesheets, que define uma extensão do padrão CSS e oferece ferramentas, para facilitar a manipulação de arquivos CSS extensos.

Parte do pacote Closure Tools e criado em Java, o projeto adiciona variáveis, funções, condicionais e mixins ao CSS. Com o Closure Stylesheets o desenvolvedor trabalha com as Google Stylesheets (GSS), que são processadas pela ferramenta para gerar arquivos CSS padrão, usados por aplicações ou sites web.

Variáveis

Variáveis são definidas usando @def:

@def BG_COLOR              rgb(235, 239, 249);
@def DIALOG_BG_COLOR       BG_COLOR;
body {
background-color: BG_COLOR;
}
.dialog {
background-color: DIALOG_BG_COLOR;
}
 
O CSS resultante para o bloco acima é:
 
body {
background-color: #ebeff9;
}
.dialog {
background-color: #ebeff9;
}

Functions

O projeto introduz uma série de funções aritméticas para a manipulação de valores númericos (ex.: medidas em pixels): add(),sub(), mult(), div(), min() e max(). Veja um exemplo com a função add():

@def LEFT_WIDTH    100px;
@def LEFT_PADDING  5px;
@def RIGHT_PADDING 5px;
.content {
position: absolute;
margin-left: add(LEFT_PADDING,
LEFT_WIDTH,
RIGHT_PADDING,
px);

Aqui está o bloco de CSS resultante:

.content {
position: absolute;
margin-left: 110px;
}

Condicionais

O Closure Stylesheets permite o uso de @if, @elseif e @else para a criação de estruturas condicionais baseadas no valor de algumas variáveis.

Mixins

Mixins são estruturas que permitem o reuso de declarações parametrizadas. Veja um exemplo:

@defmixin size(WIDTH, HEIGHT) {
width: WIDTH;
height: HEIGHT;
}
.image {
@mixin size(200px, 300px);
}

Os mixins são especialmente úteis para tratar questões de compatibilidade entre navegadores web:

@defmixin gradient(POS, HSL1, HSL2, HSL3, COLOR, FALLBACK_COLOR) {
background-color: FALLBACK_COLOR; /* fallback color if gradients are not supported */
background-image: -webkit-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);               /* Chrome 10+,Safari 5.1+ */
/* @alternate */ background-image: -moz-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR); /* FF3.6+ */
/* @alternate */ background-image: -ms-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);  /* IE10 */
/* @alternate */ background-image: -o-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);   /* Opera 11.10+ */
}
.header {
@mixin gradient(top, 0%, 50%, 70%, #cc0000, #f07575);
}

O código acima gera o seguinte resultado:

.header {
background-color: #f07575;
background-image: -webkit-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -moz-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -ms-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -o-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
}
 

O Closure Stylesheets também pode ser usado para concatenar vários arquivos CSS em um só e fazer a minificação do código. A ferramenta faz verificações estáticas na sintaxe e é capaz de inverter valores em expressões (RTL flipping), além de renomear classes.

O Closure Tools, o projeto principal que contém o Closure Stylesheets, traz um compilador, uma biblioteca e templates para a manipulação de grandes aplicações JavaScript. As ferramentas são usadas internamente pelo Google, em produtos como GMail, Google Docs e Google Maps. O projeto foi tornado open source em 2009.

Fonte: Abel Avram/traduzido por Leonardo Galvão/InfoQ

Tags | , , , , , , , ,

17

nov
2011

Sem Comentários

Em Blog

Por Allison

Closure Stylesheets do Google facilita a manipulação de código CSS extenso

Em 17, nov 2011 | Sem Comentários | Em Blog | Por Allison

O Google liberou como open source sob a Licença Apache 2.0, o projeto Closure Stylesheets, que define uma extensão do padrão CSS e oferece ferramentas, para facilitar a manipulação de arquivos CSS extensos.

Parte do pacote Closure Tools e criado em Java, o projeto adiciona variáveis, funções, condicionais e mixins ao CSS. Com o Closure Stylesheets o desenvolvedor trabalha com as Google Stylesheets (GSS), que são processadas pela ferramenta para gerar arquivos CSS padrão, usados por aplicações ou sites web.

Variáveis

Variáveis são definidas usando @def:

@def BG_COLOR              rgb(235, 239, 249);
@def DIALOG_BG_COLOR       BG_COLOR;
body {
background-color: BG_COLOR;
}
.dialog {
background-color: DIALOG_BG_COLOR;
}

O CSS resultante para o bloco acima é:

body {
background-color: #ebeff9;
}
.dialog {
background-color: #ebeff9;
}

Functions

O projeto introduz uma série de funções aritméticas para a manipulação de valores númericos (ex.: medidas em pixels): add(),sub(), mult(), div(), min() e max(). Veja um exemplo com a função add():

@def LEFT_WIDTH    100px;
@def LEFT_PADDING  5px;
@def RIGHT_PADDING 5px;
.content {
position: absolute;
margin-left: add(LEFT_PADDING,
LEFT_WIDTH,
RIGHT_PADDING,
px);

Aqui está o bloco de CSS resultante:

.content {
position: absolute;
margin-left: 110px;
}


Condicionais

O Closure Stylesheets permite o uso de @if, @elseif e @else para a criação de estruturas condicionais baseadas no valor de algumas variáveis.


Mixins

Mixins são estruturas que permitem o reuso de declarações parametrizadas. Veja um exemplo:

@defmixin size(WIDTH, HEIGHT) {
width: WIDTH;
height: HEIGHT;
}
.image {
@mixin size(200px, 300px);
}

Os mixins são especialmente úteis para tratar questões de compatibilidade entre navegadores web:

@defmixin gradient(POS, HSL1, HSL2, HSL3, COLOR, FALLBACK_COLOR) {
background-color: FALLBACK_COLOR; /* fallback color if gradients are not supported */
background-image: -webkit-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);               /* Chrome 10+,Safari 5.1+ */
/* @alternate */ background-image: -moz-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR); /* FF3.6+ */
/* @alternate */ background-image: -ms-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);  /* IE10 */
/* @alternate */ background-image: -o-linear-gradient(POS, hsl(HSL1, HSL2, HSL3), COLOR);   /* Opera 11.10+ */
}
.header {
@mixin gradient(top, 0%, 50%, 70%, #cc0000, #f07575);
}

O código acima gera o seguinte resultado:

.header {
background-color: #f07575;
background-image: -webkit-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -moz-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -ms-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
background-image: -o-linear-gradient(top,hsl(0%,50%,70%) ,#cc0000);
}

O Closure Stylesheets também pode ser usado para concatenar vários arquivos CSS em um só e fazer a minificação do código. A ferramenta faz verificações estáticas na sintaxe e é capaz de inverter valores em expressões (RTL flipping), além de renomear classes.

O Closure Tools, o projeto principal que contém o Closure Stylesheets, traz um compilador, uma biblioteca e templates para a manipulação de grandes aplicações JavaScript. As ferramentas são usadas internamente pelo Google, em produtos como GMail, Google Docs e Google Maps. O projeto foi tornado open source em 2009.

Fonte: Postado por Abel Avram , traduzido por Leonardo Galvão/InfoQ

Tags | , , , ,

13

nov
2011

Sem Comentários

Em Blog

Por Allison

Usando Ajax com jQuery

Em 13, nov 2011 | Sem Comentários | Em Blog | Por Allison

Realmente eu achava chato programar em javascript, algo complicado, cheio de lerolero, mas então eu encontrei o jQuery, e programar em javascript se tornou algo fácil e muito divertido. Realmente eu fiquei muito feliz a descobrir este framework (se é que pode ser chamado assim). Hoje vou falar de uma das funcionalidades mais uteis e mais requisitadas que podemos usar para sistemas web, o ajax.

Tirando da Wikipedia: AJAX (acrônimo em língua inglesa de Asynchronous Javascript And XML) é o uso metodológico de tecnologias como Javascript e XML, providas por navegadores, para tornar páginas Web mais interativas com o usuário, utilizando-se de solicitações assíncronas de informações. Mas na linguagem mais simples, conseguimos fazer uma requisição a um arquivo (pagina) sem precisar fazer reload de tela. Sim, isto torna muito mais rápido a execução do seu código, e muito mais bonito e elegante tbm.

Uma coisa que vamos aprender como jQuery é que vamos separar totalmente o nosso código javascript do nosso html. Gosto de pensar a programação web em camadas, sendo elas: conteúdo (html), estilo (css) e ação (javascript). Ainda temos a tomada de decisão (php), mas acho que falar sobre isto é coisa para outro tutorial. Vamos ao que interessa.

Primeiro, precisamos baixar o jQuery direto da fonte: http://docs.jquery.com/Downloading_jQuery

Vamos entender como funciona a estrutura básica:

<!doctype html>
<html>
  <head>
    <!-- aqui vamos fazer o nosso include da biblioteca do jQuery -->
    <script type="text/javascript" src="jquery.js"></script>
 
    <script type="text/javascript">
      <!-- aqui vamos escrever nosso código javascript -->
    </script>
  </head>
  <body>
    <a href="http://jquery.com/">jQuery</a>
  </body>
</html>

Muito simples, fizemos a requisição do nosso arquivo jQuery, e logo em seguida escrevemos nosso código entre as tags .

Mas vamos agora ao nosso código:

<!doctype html>
<html>
  <head>
 
    <script type="text/javascript" src="jquery.js"></script>
 
    <script type="text/javascript">
    $(document).ready(function(){
      $("#button_busca").click(function () {
        $("form").submit(function () { return false; });
        var busca = $("#busca").val();
        $.ajax({
            type: "POST",
            url: "busca.php",
            data: "busca="+busca,
            success: function(html){
                $("#resposta").html(html);
            }
        });
    });
    });
    </script>
  </head>
  <body>
    <div id="resposta"> </div>
    <form>
    <fieldset>
        <legend>Busca</legend>
        <dl>
            <dt><label for="busca">Palavra Chave:</label></dt>
            <dd><input type="text" name="busca" id="busca" /></dd>
        <dd class="botao"><button id="button_busca">Busca</button></textarea></dd>
            </dl>
    </fieldset>
    </form>
  </body>
</html>

Primeiro fazemos o include da biblioteca jQuery. Depois temos a linha: “$(document).ready(function(){” isto faz com que assim que a pagina termine de ser carregada ele aplique as rotinas que vamos escrever abaixo dele. Abaixo temos “$(“#button_busca”).click(function () {” que vai associar ao id button_busca uma ação quando ele for clicado.

Usamos a função “$(“form”).submit(function () { return false; });” para que quando o botão for clicado ele não faça um reload de tela enviando para a action do form.

Criamos uma variável e atribuímos a ela o valor que estiver no campo de input com o id busca (“var busca = $(“#busca”).val();”).

A nossa chamada ajax ocorre na linha 13, onde chamamos a função e passamos os parâmetros:

  • type: tipo de encoding que vai ser enviado para o arquivo.
  • url: caminho completo do arquivo que vai ser requisitado.
  • data: os valores que serão passados, no nosso exemplo estão passando a variável busca, com o valor que pegamos do input com o id busca.
  • success: dizemos que caso tudo funcione ok, execute isto, no nosso caso estamos pegando o retorno da requisição e jogando o mesmo como html na div de id resposta.

Segue ainda o código php:

<?php
       echo "Resultado da Consulta aqui: $_POST[busca]";
?>

Fonte: Rafael Cirolini/NerdHead

Tags | , , , , , ,

10

nov
2011

Sem Comentários

Em Blog

Por Allison

Lançado Sqlsus 0.7

Em 10, nov 2011 | Sem Comentários | Em Blog | Por Allison

Sqlsus é uma ferramenta open source de SQL injection (MySQL) e takeover, escrita em Perl. Através de uma interface de linha de comando, ela possibilita recuperar a estrutura de um banco de dados, injetando suas próprias consultas SQL (mesmo as mais complexos), realizar download de arquivos do servidor Web, rastrear o site para diretórios graváveis, fazer upload, controlar um backdoor, entre outras funcionalidades.

Sqlsus concentra-se na velocidade e eficiência, otimizando o space injection disponível. Além disso, ele oferece uma interface fácil de usar, com muitas características interessantes e peculiares. Na versão 0.7, Sqlsus recebe a adição de uma progress bar para o modo “inband”, que determina o número de linhas a ser devolvido antes de consultá-las.

Aos interessados em fazer download e testar o utilitário, a sua nova versão está disponível a partir do sistema de hospedagens do Source Forge.

Post original em http://sqlsus.sourceforge.net/download.html

Fonte: Under-Linux

Tags | , , , , ,

03

nov
2011

Sem Comentários

Em Blog

Por Allison

WebMatrix 2.0 – o que ele traz de melhor e porque você deveria conhecê-lo!

Em 03, nov 2011 | Sem Comentários | Em Blog | Por Allison

Já falamos aqui das novidades do WebMatrix em 2011, e também já mostramos como ele pode ajudar para que você faça a web de forma simples, rápida e muito eficiente. Mas você sabe como isso realmente afeta a sua vida, o seu trabalho?

O WebMatrix é um IDE (Integrated Development Enviroment – Ambiente de desenvolvimento integrado) que utiliza o Web Platform Installer para instalar e configurar automaticamente os componentes de software necessários para desenvolver uma determinada aplicação. Isso quer dizer, simplesmente, que ele vai te ajudar a “instalar” tudo aquilo que você precisa para fazer um site, como um Blog WordPress, sem precisar conhecer nada de programação. Hoje, 2/3 da web é baseada em web applications prontas, testadas e aprovadas. Não é necessário mais arriscar.

Como tudo, o WebMatrix está em constante evolução. E a versão 2.0 ganhou alguns diferenciais importantes, que vão facilitar a sua vida, deixando-o independente dentro da web, permitindo que você possa criar o seu site, mesmo que você não seja um desenvolvedor ou que esteja começando nessa área.

Uma das novidades são os novos templates disponíveis, que facilitam a criação de websites, e aplicativos web. Não bastassem os templates, o WebMatrix possui um novo sistema de code complete que auxilia o usuário a escolher as cores utilizadas no CSS graficamente.

Outro ponto que essa versão trabalhou foi o incentivo aos usuários para que eles entendam as tecnologias as quais a ferramenta dá suporte. Sendo assim, eles passaram a disponibilizar diversos tutoriais, com exemplos bem detalhados, para que o usuário possa entender a codificação à medida que ela ocorre.

Ainda seguindo a linha de pensamento “fazer a web de forma mais simples”, o WebMatrix implementou nessa versão os Helpers, que são blocos de códigos que podem ser utilizados na sua aplicação WebMatrix como atalhos simplificados para integração com ferramentas como redes sociais, por exemplo. A galeria de Helpers é aberta e você já encontrará facilmente a integração com Facebook, Twitter, Foursquare, PayPal, dentre outros.

Outra novidade é o relatório WebMatrix SEO (Search Engine Optimization), que é uma ferramenta que analisa o seu site e dá sugestões, quando necessário, para corrigir o que está errado. Com esta ferramenta você pode melhorar o posicionamento do seu site para os motores de busca.

Você já tem um site publicado e ficou arrependido de não ter utilizado o WebMatrix? Não precisa. Você também pode conectar a sites já publicados, utilizando o WebMatrix, alterar e fazer o upload diferente.

O WebMatrix ainda oferece um gerenciador visual de banco de dados com uma interface simples e amigável para Sql Server 2005/2008 e MySQL 5.x/6.x, mas se você não possui servidor de banco de dados não se preocupe! O WebMatrix possui um pequeno servidor de banco de dados incorporado o Sql Server Compact e ainda utiliza o Web Plataform Installer para instalar e configurar automaticamente o MySQL caso seja necessário.

Fonte: IMasters

Tags | , , , , , , , , , ,

28

set
2011

Sem Comentários

Em Blog

Por Allison

O que exatamente é o NodeJS

Em 28, set 2011 | Sem Comentários | Em Blog | Por Allison

Se você ouviu falar do Node, ou leu artigos que proclamam como ele é maravilhoso, poderá estar pensando: “Afinal, o que é Node.js?”. Apesar de não ser para todos, o Node pode ser a escolha certa para algumas pessoas.

Este artigo buscará responder o que é o Node.js resumindo o problema que ele pode resolver, como ele funciona, como executar um aplicativo simples e, finalmente, quando o Node é ou não é uma boa solução. Ele não abordará como escrever um aplicativo Node complicado nem será um tutorial completo sobre Node. A leitura deste artigo o ajudará a decidir se você deverá buscar aprender Node para usar em seu próprio negócio.

Que problema o Node soluciona?

O objetivo declarado do Node é “fornecer uma maneira fácil de criar programas de rede escaláveis”. Qual é o problema com os programas de servidor atuais? Vamos fazer as contas. Em linguagens como Java™ e PHP, cada conexão inicia um novo encadeamento que, potencialmente, é acompanhado de 2 MB de memória. Em um sistema que tenha 8 GB de RAM, isto define o número máximo teórico de conexões simultâneas em cerca de 4.000 usuários.

À medida que sua base de clientes cresce, você deseja que seu aplicativo da Web suporte mais usuários e, portanto, será necessário adicionar mais servidores. É claro, isso se soma a custos de negócios, especificamente custos de servidor, custos de tráfego e custos de mão de obra. Adicione a esses custos o problema técnico potencial de que um usuário poderá usar diferentes servidores para cada solicitação, de forma que quaisquer recursos compartilhados deverão ser compartilhados por todos os servidores. Por exemplo, no Java, variáveis estáticas e caches precisam ser compartilhados entre as JVMs em cada servidor. Este é o gargalo de toda a arquitetura de aplicativos da web, o número máximo de conexões simultâneas que um servidor pode tratar.

O Node soluciona o problema mudando a forma como uma conexão é feita no servidor. Em vez de iniciar um novo encadeamento do SO para cada conexão (e alocar a memória correspondente com ele), cada conexão cria um processo, que não requer que o bloco de memória o acompanhe. O Node alega que nunca ocorrerá um impasse de bloqueios, pois não são permitidos bloqueios e ele não bloqueia diretamente para realizar chamadas de E/S. O Node também alega que um servidor que o execute pode suportar dezenas de milhares de conexões simultâneas. De fato, o Node altera o panorama do servidor ao mudar o gargalo do sistema inteiro do número máximo de conexões para a capacidade de tráfego de um único sistema.

Portanto, agora que você tem um programa que pode tratar dezenas de milhares de conexões simultâneas, o que você pode de fato criar com o Node? Seria ótimo se você tivesse um aplicativo da Web que exigisse tantas conexões. Este é um daqueles problemas do tipo “se você tem esse problema, ele não é um problema”. Antes de chegarmos a isso, vejamos como o Node funciona e como foi projetado para ser executado.

O que o Node definitivamente não é

Sim, o Node é um programa de servidor. No entanto, ele definitivamente não é como o Apache ou o Tomcat. Esses servidores são produtos de servidor independentes, prontos para instalar e implementar aplicativos instantaneamente. Você poderá ter um servidor em execução em um minuto com esses produtos. O Node definitivamente não é isso.

O Apache pode adicionar um módulo PHP para permitir que os desenvolvedores criem páginas da Web dinâmicas, e os programadores usando Tomcat podem implementar JSPs para criar páginas da Web dinâmicas. O Node definitivamente não é isso.

Neste momento inicial da vida do Node (atualmente na versão 0.4.6), ele não é um programa de servidor pronto para ser executado, onde você espera instalá-lo, colocar seus arquivos dentro dele e ter um servidor da Web totalmente funcional. Ele ainda requer uma quantidade de trabalho não trivial para obter até mesmo a funcionalidade básica de um servidor da Web funcionando depois de concluir a instalação.

Como o Node funciona

O Node propriamente dito executa V8 JavaScript. Espere, JavaScript no servidor? Sim, você leu corretamente. O JavaScript no lado do servidor é um conceito relativamente novo, e há cerca de dois anos, aqui no developerWorks, ele foi mencionado em uma discussão sobre o produto Aptana Jaxer. Apesar de o Jaxer nunca ter chegado a tanto, a ideia em si não era tão absurda — por que não usar no cliente a mesma linguagem de programação que você usa no servidor?

O que é o V8?

O mecanismo V8 JavaScript é o mecanismo subjacente do JavaScript que o Google usa com seu navegador Chrome. Poucas pessoas pensam sobre o que de fato ocorre com o JavaScript no cliente. Um mecanismo JavaScript, de fato, interpreta o código e o executa. Com o V8, o Google criou um interpretador ultrarrápido escrito em C++ que tem um aspecto exclusivo: é possível fazer o download do mecanismo e integrá-lo em qualquer aplicativo que você desejar. Ele não é restrito à execução em um navegador. Portanto, o Node, na verdade, usa o mecanismo V8 JavaScript escrito pelo Google e o redireciona para uso no servidor. Perfeito! Por que criar uma nova linguagem quando há uma boa solução já disponível.

Programação direcionada a eventos

Muitos programadores foram ensinados a acreditar que a programação orientada a objeto é o projeto de programação perfeito e a não usarem nada mais. O Node utiliza o que é chamado de modelo de programação direcionado a eventos.

Listagem 1. Programação direcionada a evento no lado do cliente com jQuery

// jQuery code on the client-side showing how Event-Driven programming works When a button is pressed,
// an Event occurs - deal with it directly right here in an anonymous function, where all the necessary
//variables are present and can be referenced directly

$("#myButton").click(function(){

if ($("#myTextField").val() != $(this).val())

alert("Field must match button text");

});

O lado do servidor, na verdade, não é diferente do lado do cliente. Verdade, não é preciso pressionar botões, nem digitar em campos de texto, mas, em um nível mais alto, eventos estão ocorrendo. Uma conexão é feita – evento! Dados são recebidos pela conexão – evento! Dados param de chegar pela conexão – evento!

Por que este tipo de configuração é ideal para o Node? O JavaScript é uma excelente linguagem para programação direcionada a eventos, pois permite funções e fechamentos anônimos e, mais importante, a sintaxe é familiar para quase todos que alguma vez já programaram. As funções de callback, que são chamadas quando um evento ocorre, podem ser escritas no mesmo local onde você captura o evento. Portanto, é fácil de codificar, fácil de manter, sem estruturas orientadas a objetos complicadas, sem interfaces e sem potencial para excessos na arquitetura. Basta aguardar um evento, escrever uma função de callback e a programação direcionada a eventos toma conta de tudo!

Exemplo de aplicativo Node

Finalmente vamos ver algum código! Vamos juntar tudo o que discutimos e criar nosso primeiro aplicativo Node. Como vimos que o Node é ideal para tratar aplicativos com alto tráfego, vamos criar um aplicativo da Web muito simples, criado para oferecer velocidade máxima.

Eis as especificações de nosso aplicativo de amostra transmitidas pelo “chefe”: criar uma API ReSTful geradora de números randômicos. O aplicativo deverá receber uma entrada, um parâmetro chamado “number”. O aplicativo, a seguir, retornará um número randômico entre 0 e este parâmetro, e retornará o número gerado para o chamador. Como o “chefe” espera que esse aplicativo seja extremamente popular, ele deverá tratar 50 mil usuários simultâneos. Vamos ver o código:

Listagem 2. Gerador de número randômico do Node

// these modules need to be imported in order to use them. Node has several modules. They are like
// any #include or import statement in other languages

var http = require("http");

var url = require("url");

// The most important line in any Node file. This function does the actual process of creating
// the server. Technically, Node tells the underlying operating system that whenever a connection
// is made, this particular callback function should be executed. Since we're creating a web
// service with REST API, we want an HTTP server, which requires the http variable we created
// in the lines above. Finally, you can see that the callback method receives a 'request'

// and 'response' object automatically. This should be familiar to any PHP or Java programmer.

http.createServer(function(request, response) {
// The response needs to handle all the headers, and the return codes These types of things are handled

// automatically in server programs like Apache and Tomcat, but Node requires everything to be done yourself

response.writeHead(200, {"Content-Type": "text/plain"});

// Here is some unique-looking code. This is how Node retrieves parameters passed in from client requests.

// The url module handles all these functions. The parse function deconstructs the URL, and places the query

// key-values in the query object. We can find the value for the "number" key by referencing it directly -

// the beauty of JavaScript.

var params = url.parse(request.url, true).query;

var input = param.number;

// These are the generic JavaScript methods that will create our random number that

// gets passed back to the caller

var numInput = new Number(input);

var numOutput = new Number(Math.random() * numInput).toFixed(0);

// Write the random number to response

response.write(numOutput);

// Node requires us to explicitly end this connection. This is because

// Node allows you to keep a connection open and pass data back and forth,

// though that advanced topic isn't discussed in this article.

response.end();

// When we create the server, we have to explicitly connect the HTTP server to

// a port. Standard HTTP port is 80, so we'll connect it to that one.
}).listen(80);

// Output a String to the console once the server starts up, letting us know everything starts up correctly

console.log("Random Number Generator Running...");

Iniciando esse aplicativo

Coloque o código acima em um arquivo chamado “random.js”. Agora, para iniciar esse aplicativo e executá-lo (portanto, criar o servidor HTTP e aguardar conexões na porta 80), simplesmente execute o comando a seguir em seu prompt de comando: % node random.js. Eis o que se parecerá quando o servidor estiver em execução.

root@ubuntu:/home/moilanen/ws/mike# node random.js

Random Number Generator Running...

Acessando esse aplicativo

O aplicativo está em execução. O Node está aguardando conexões neste momento, então vamos testar o aplicativo. Como criamos uma API RESTful simples, podemos acessar o aplicativo usando nosso navegador. Digite o seguinte endereço (assegure-se de ter completado a etapa anterior): http://localhost/?number=27.

A janela de seu navegador mudará para um número aleatório entre 0 e 27. Pressione recarregar em seu navegador e obterá outro número randômico. E aí está, seu primeiro aplicativo Node!

Node, para que ele serve?

Depois de ler tudo sobre o Node, você poderá responder o que ele é, mas ainda imaginará quando deverá usá-lo. Essa é uma pergunta importante a fazer, pois existem certas coisas para as quais o Node é bom e, de forma contrária, há certas coisas para as quais o Node, no momento, provavelmente não é uma boa solução. Você precisa decidir cuidadosamente quando usar o Node, pois usá-lo na situação errada poderá levar a MUITA codificação extra.

Para o que ele é bom

Como você viu até agora, o Node é extremamente bem projetado para situações em que um grande volume de tráfego é esperado e a lógica e o processamento necessários do lado do servidor não são necessariamente volumosos antes de responder ao cliente. Bons exemplos de onde o Node seria excelente incluem:

  • Uma API RESTful – Um serviço da Web que forneça uma API RESTful recebe alguns parâmetros, interpreta-os, monta uma resposta e envia-a (normalmente uma quantidade relativamente pequena de texto) de volta ao usuário. Esta é uma situação ideal para o Node, pois você poderá criá-lo para tratar dezenas de milhares de conexões. Ela também não requer um grande volume de lógica; ela simplesmente procura valores em um banco de dados e monta uma resposta. Como a resposta é uma pequena quantidade de texto e a solicitação de entrada é uma pequena quantidade de texto, o volume de tráfego não é grande, e um computador poderá provavelmente tratar as demandas de API mesmo da API da empresa mais movimentada.
  • Fila do Twitter – Pense em uma empresa como a Twitter, que precisa receber tweets e gravá-los em um banco de dados. Existem literalmente milhares de tweets chegando a cada segundo e o banco de dados não consegue acompanhar o número de gravações necessárias durante os momentos de pico de uso. O Node torna-se uma engrenagem importante na solução deste problema. Como vimos, o Node consegue tratar dezenas de milhares de tweets que chegam. Ele pode gravá-los rápida e facilmente em um mecanismo de enfileiramento em memória (memcached, por exemplo), a partir do qual outro processo separado pode gravá-los no banco de dados. A função do Node é rapidamente coletar o tweet e passar essa informação para outro processo, responsável por gravá-lo. Imagine outro projeto — um servidor PHP normal que tenta tratar gravações no banco de dados em si — cada tweet causaria um pequeno atraso ao ser gravado pelo banco de dados, pois a chamada ao banco de dados estaria sendo bloqueada. Uma máquina com este design só poderia ser capaz de tratar 2000 tweets por segundo, devido à latência do banco de dados. Um milhão de tweets por segundo requer 500 servidores. O Node, em vez disso, trata cada conexão e não bloqueia, possibilitando que ele capture o máximo de tweets possível. Uma máquina com Node, capaz de tratar 50.000 tweets por segundo, requer somente 20 servidores.
  • Servidor de arquivos de imagem – Uma empresa que tem um grande Web site distribuído (pense no Facebook ou Flickr) poderia decidir dedicar servidores inteiros a simplesmente servir imagens. O Node seria uma boa solução para esse problema, pois a empresa pode usá-lo para codificar um recuperador de arquivos fácil e, a seguir, tratar dezenas de milhares de conexões. O Node procuraria pelo arquivo de imagem, retornaria o próprio arquivo ou um erro 404 e não faria mais nada. Essa configuração permitiria que esses tipos de Web sites distribuídos reduzissem o número de servidores necessários para servir arquivos estáticos, como imagens, arquivos .js e arquivos .css.

Para o que ele não serve

É claro, o Node não é a escolha ideal em algumas situações. Eis alguns cenários em que o Node não seria bom:

  • Páginas criadas dinamicamente – Atualmente, o Node não fornece uma forma padrão para criar páginas dinâmicas. Por exemplo, ao usar a tecnologia JavaServer Pages (JSP), é possível criar uma página index.jsp que contenha loops em snippers JSP, como <% for (int i=0; i<20; i++) { } %>. O Node não permite esses tipos de páginas dinâmicas direcionadas a HTML. Novamente, o Node não é idealmente adequado para ser um servidor de páginas da web, como o Apache e o Tomcat o são. Portanto, se quisesse fornecer uma solução no lado do servidor para isto no Node, teria que codificar a solução inteira você mesmo. Um programador PHP não gostaria de programar um conversor PHP para o Apache toda vez que implementasse um aplicativo da web, mas, neste momento, é o que o Node exigiria que você fizesse.
  • Aplicativos pesados em bancos de dados relacionais – O Node foi projetado para ser rápido, assíncrono e sem bloqueio. Os bancos de dados não necessariamente compartilham desses objetivos. Eles são síncronos e com bloqueio, pois chamadas ao banco de dados para leitura e gravação bloqueiam até que um resultado seja gerado. Portanto, um aplicativo da Web que solicite muitas chamadas ao banco de dados, muitas leituras e muitas gravações com cada solicitação seria uma aplicação ruim para o Node, pois o banco de dados relacional em si estaria negando muitos dos pontos fortes do Node. (Os novos bancos de dados NoSQL são uma escolha melhor para o Node, mas este é um tópico totalmente diferente).

Conclusão

A pergunta “O que é Node.js?” deve estar respondida. Depois de ler esse artigo, você deverá ser capaz de explicar, em poucas frases claras e concisas, o que é o Node.js. Se puder fazer isso, você está à frente de muitos codificadores e programadores. Muitas pessoas com quem conversei sobre o Node ficaram confusas sobre o que exatamente ele faz. Eles estão, compreensivelmente, com a postura mental do Apache — um servidor é um aplicativo no qual você coloca seus arquivos HTML e tudo funciona. O Node é direcionado a finalidade. É um software que usa JavaScript para permitir que os programadores rápida e facilmente criem servidores da Web rápidos e escaláveis. Onde o Apache é pronto para executar, o Node é pronto para codificar.

O Node atinge seus objetivos fornecendo servidores altamente escaláveis. Ele não aloca um modelo de encadeamento por conexão, mas usa um modelo processo por conexão, criando somente a memória que é necessária para cada conexão. Ele usa um mecanismo JavaScript extremamente rápido do Google, o mecanismo V8. Ele usa um projeto direcionado a eventos para manter o código mínimo e fácil de ler. Todos esses fatores levam ao objetivo desejado do Node — é relativamente fácil escrever uma solução altamente escalável.

Tão importante quanto entender o que o Node é, é entender o que ele não é. O Node não é simplesmente uma substituição para o Apache que tornará seu aplicativo PHP da Web mais escalável. Isto não pode estar mais longe da verdade. Neste estágio preliminar da vida do Node, ele tem um potencial limitado para uso por muitos programadores, mas nas situações em que faz sentido usá-lo, ele funciona extremamente bem.

O que se pode esperar do Node no futuro? Essa é, talvez, a pergunta mais importante a levar deste artigo. Agora que você sabe o que ele faz, procure saber o que ele fará a seguir. No próximo ano, espero que o Node ofereça melhor integração com bibliotecas de suporte de terceiros existentes. No momento, muitos programadores terceiros desenvolveram plugins para o Node, incluindo a adição de suporte ao servidor de arquivos e ao MySQL. Espero que o Node comece a integrar isso na funcionalidade principal.

Eventualmente, também espero que o Node suporte algum tipo de módulo de página dinâmica, permitindo fazer os tipos de coisas em um arquivo HTML que é possível fazer no PHP e JSPs (talvez uma NSP, página de servidor Node). Finalmente, em algum momento, espero um servidor Node pronto para implantação, que você faça o download, instale e simplesmente coloque seus arquivos HTML dentro dele como faria com o Apache ou o Tomcat. Ainda é cedo na vida do Node, mas ele está crescendo rapidamente e poderá, em breve, estar em seu horizonte.

Recursos

Aprender

Obter produtos e tecnologias

Artigo originalmente publicado em IBM developerWorks http://www.ibm.com/developerworks/br/library/os-nodejs/index.html

Fonte: Michael Abernethy/IMaster

Comentário SWX

Conteúdo muito relente. Para ser lido ao menos duas vezes.

Tags | , , , , , , , , , , ,

20

set
2011

Sem Comentários

Em Blog

Por Allison

A importância do ASA (Application Server Admin)

Em 20, set 2011 | Sem Comentários | Em Blog | Por Allison

Todo mundo que estuda um pouquinho do funcionamento de um Application Server repara logo que existe a necessidade de pessoas para zelarem pelo seu funcionamento e responderem pela sua administração. O Servidor de Aplicação está para o ASA (App. Server Admin), assim como o Banco de Dados está para o DBA. A diferença é que no modelo de desenvolvimento Cliente-Servidor ainda não existia a necessidade do ASA, já que não havia a existência do Servidor de Aplicação.

Acho um assunto muito interessante, e pesquisando sobre isso, verifiquei que já existiam artigos tão bons e que tratam o tema de maneira tão completa que dispensa a criação de outro artigo sobre o mesmo assunto.

Repasso para que vocês possam ler a matéria completa.

O ‘Deployer’ ou Administrador é a pessoa (ou empresa) responsável por configurar e realizar o deploy de aplicações Java EE, administrar a infraestrutura de computação e rede onde aplicações Java são executados, e monitora o ambiente de execução. Entre suas atribuições, está o ajuste dos controles transicionais e atributos de segurança, além de especificar conexões de Banco de Dados.

Essa é a definição oficial da Sun para o perfil “Application Deployer and Administrator“, segundo o Tutorial Java EE.

Desde quando comecei a trabalhar com o Java EE na sua versão 1.3, toda a equipe ganhou “de brinde” uma nova atribuição: Administrar o servidor de aplicações! Claro que no ínicio tudo não passava de alguns deploys e restarts. Com o amadurecimento foi inevitável o crescimento da quantidade de componentes, bibliotecas, datasources, filas JMS e também do “parque” de servidores de aplicação; esta nova atribuição já tomava um tempo considerável da equipe. Foi assim que resolvemos seguir a “sugestão” da Sun e contratar um perfil específico para esta função.

É comum as pessoas que tem seu primeiro contato com o Java EE, enxergarem o Servidor de Aplicações como uma espécie de Web Server estando ele para o Java, como o mod_php/Apache está para o PHP ou como o IIS está para o ASP. Na verdade, como diz Bruno Souza (o Javaman), o Java EE é uma especificação! É um documento que pode ser obtido na página da JSR 244! O Servidor de aplicação nada mais é que a implementação do que foi especificado. Não vou entrar no mérito da compatibilidade do Servidor com sua especificação mas sim deixar claro que o Servidor de Aplicações é muito mais que um Web Container Java e entre os serviços providos pelo Servidor de Aplicação estão: e-Mail (Java Mail), Transação (JTA), Filas (JMS), Conectores (JCA), Segurança (JAAS), Monitoramento (JMX), Pool (Conexão e EJBs), Registro de nomes (JNDI), além dos conteiners de EJBs (Entity Beans, Session Beans e Message Driven Beans); WEB (JSP, Servlets, JSTL e JSF) entre outros.

Cada um desses serviços possui suas próprias configurações como números de Threads, número máximo e mínimo dos Pools, sem contar o próprio tunning da JVM (Não deixem de ver a palestra do Cláudio Miranda – Performance em Aplicações Java). Fora essas atribuições, o ASA (Application Server Admin) também é responsável por: Realizar o deploy da aplicação Java EE, Configurar a aplicação Java (modificando os descritores) para se adequar ao ambiente operacional, Verificar o conteúdo da aplicação e garantir que o arquivo está de acordo com a especificação Java EE e também que as dependências de bibliotecas de terceiros estão corretas (e não quebram a compatibilidade com a API de outras aplicações no servidor).

Como é possível ver, para praticamente todas as atividades citadas, é necessário um conhecimento específico da plataforma JAVA. Entretanto, o que muito se vê nas corporações é a administração do Servidor de Aplicações sendo realizada pela “equipe da rede”, na qual muitas vezes a instalação do Servidor é feita através do apt-get, descompactação do ZIP ou “Next, Next, Finish”. O resultado é que muitas vezes o servidor é executado com uma configuração padrão para a JVM (o que é insuficiente na maioria dos casos), nível de Logging e segurança: Basta ver a quantidade de servidores JBoss na internet que possuem o JMX console aberto (permitindo total controle da instância).

Não é nenhum exagero dizer que hoje, assim como todos os Bancos de Dados sérios e críticos precisam de um excelente DBA, também todos os Servidores de Aplicações sérios e críticos precisam de um ASA. É perceptível o nível de profissionalismo que uma empresa atinge quando o profissional implanta servidores de aplicações com alta disponibilidade; sistemas de monitoramento que notificam o Administrador quando o Servidor está indisponível ou próximo do limite de Threads e Pools e ainda é capaz de rastrear data, hora e versão da aplicação disponibilizada em produção.

Não deixem de considerar esse perfil se quiserem aumentar o profissionalismo das aplicações/ambiente Java EE!

Fonte: Lúcio Camilo/IMaster

Tags | , , , , , , ,