20 de janeiro de 2011

Lições sobre a cloud computing

O texto abaixo reproduz uma matéria publicada na ComputerWorld que elenca cinco características da computação na nuvem que parecem ter sido melhor assimiladas no ano que passou, gerando uma melhor compreensão do significado dessa tecnologia e que deverão ser usadas como base para os próximos níveis de adoção. A matéria original pode ser acessada aqui.
2010 foi o ano em que a "computação na nuvem" (cloud computing) se tornou apenas “nuvem” (cloud), e todos perceberam que “nuvem”, “SaaS” e todos os outros XaaS (PAAS, IAAS, DAAS) eram implementações diferentes da mesma ideia – um conjunto de serviços de computação disponíveis online que se podem expandir ou contrair de acordo com as necessidades.

Nem toda a confusão foi esclarecida, claro. Mas, vendo os serviços específicos oferecidos pela Amazon, Microsoft, Oracle, Citrix, VMware e uma série de outras empresas, muitos profissionais de TI puderam ter uma ideia mais concreta do que a “nuvem” é realmente.

Cinco aspectos se tornaram mais claros até mesmo para os mais experientes gestores de TI. São eles:

1. Nuvens “externas” e “internas” não são tão diferentes
No início de 2010, a questão mais comum era se a nuvem deveria ser inserida no firewall ou contratada fora.

Uma vez que os mesmos dados e aplicações empresariais migrem para a nuvem, interna (em servidores dentro do firewall) ou pública, a empresa proprietária dos dados enfrenta o mesmo risco. Razão pela qual muitas empresas estejam apostando mais em nuvens “híbridas” do que apenas internas ou públicas, de acordo com o guru da virtualização da Gartner, Chris Wolf.

“Com as nuvens internas, tem-se uma determinada quantidade de benefícios desde a partilha de recursos e eficiência, mas não se tem a elasticidade que é o real motivo para a venda da nuvem”, explicou Wolf à CIO.com.

2. De que são feitas as nuvens? De outras nuvens
Durante 2010, muitas empresas de computação na nuvem minimizaram o papel da virtualização e da visão “end-to-end” da VMware, na qual as empresas usam infraestruturas de servidores virtuais para suportar o compartilhamento de recursos e a gestão de recursos na nuvem dentro do firewall, antes de partir para o uso da nuvem pública.

Os fornecedores de cloud computing oferecem aplicações, armazenamento, poder de computação, etc., à vontade, sob demanda, através de uma ligação à Internet, sem a necessidade de ter uma infraestrutura de servidores virtuais dentro da empresa.

Os dois ambientes, por definição, são virtualizados, concordam os analistas. E quase sempre estão instalados em centros de dados, “parques” de servidores virtuais ou até mesmo em serviços completos de cloud fornecidos por outras empresas.

3. “Nuvens” não libertam as TI de “porcas e parafusos”
Há uma suposição de que a cloud computing consiga tornar sofisticados serviços de TI transparentes para o usuário final, fazendo com que deixem de se preocupar com o hardware e o software que os executam.

Isso não significa que as pessoas que gerem os servidores não tenham que conhecer do seu negócio, de acordo com Bob Laliberte, analista no Enterprise Strategy Group. Suportar as clouds significa tornar os servidores, armazenamento, redes e aplicações mais rápidos e estáveis, com menos atrasos do que nunca, segundo Vince DiMemmo, gestor de cloud e serviços de TI no prestador de serviços e infra-estrutura do centro de dados Equinix.

Sem infra-estrutura “à prova de balas”, a computação na nuvem é lenta, diz, e os usuários finais não aceitam a lentidão.

4. Pequenas coisas fazem grandes diferenças
A virtualização permite que várias aplicações e sistemas operacionais sejam executados pelo mesmo hardware, como se cada um deles tivesse o seu próprio servidor. O problema com isso, diz o analista da IDC, Gary Chen, é que todos pensam que têm a interface de rede e o “bus” de entrada/saída (input/output para o processador também só para si.

Em um servidor com variados sistemas operacionais virtuais, o “engarrafamento” para o desempenho já não é a velocidade com que os dados podem ir e vir entre o servidor e o armazenamento externo, mas o número de bits que podem passar pelo “bus” de dados ao mesmo tempo, diz Chen.

Essa é uma razão pela qual o Virtual I/O esteja se tornando um tema cada vez mais "quente", levando ao que o analista da Forrester, John Rymer, chama de “virtualização distribuída” – na qual I/O, memória e outros componentes são abstraídos uns dos outros, assim como os sistemas operacionais externos, e a definição de “servidor” altera-se para significar que recursos uma aplicação necessita no momento.

5. “Ano - e não Era - do Desktop Virtual”
2010 era para ser o Ano do Desktop Virtual, com a Microsoft, Citrix e VMware competindo para capturar o que os analistas esperavam ser uma onda de adopção das empresas.

Os desktops virtuais foram um tema quente em 2010 mas o crescimento não foi tão grande quanto os analistas ou fornecedores esperavam.

Em vez de padronizar os desktops virtuais e mover todos os seus utilizadores imediatamente para facilitar a migração para o Windows 7, a maioria das empresas adotou por um número crescente de “sabores” da tecnologia, mas apenas onde fazia mais sentido.

“Estamos vendo um monte de projetos táticos, mas não um monte de projetos estratégicos”, diz o analista da IDC, Ian Song.

Isso não quer dizer que não tenha havido um grande crescimento ou adoção até das versões DAAS. Mas 2010 não foi uma onda, diz Song.

As duas principais razões, segundo ele, foram a complexidade e o ROI comparativamente baixo da virtualização de desktops em relação aos servidores virtuais. Outro foi o crescente foco – até dentro das empresas – dos tablets, smartphones e outros dispositivos não-PC que têm de ser virtualizados para se tornarem seguros, confiáveis para clientes de aplicações empresariais.

“Esperamos ouvir muito sobre isso da Citrix e da VMware e de um conjunto de operadoras de telecomunicações” este ano, diz Song. E “vai ser grande”.


17 de janeiro de 2011

Criando Esquema para validar um XML - parte V

Nos exemplos incluídos no último post, as regras de validação se baseiam na especificação de uma cadeia de caracteres permitidos, sendo que cada posição no texto final tem que estar declarada na regra. Embora isso resolva as situações em que o tamanho do texto exigido é fixo - como no caso do código de um produto - , é bastante inconveniente termos que declarar cada caracter quando o tamanho do texto é muito grande. Isso é especialmente verdade quando as regras para cada caracter se repetem ao longo do padrão.

Imagine, por exemplo, criar a regra de validação para um campo texto de 255 caracteres em que apenas letras maiúsculas e dígitos são aceitos. Pela forma apresentada no outro post, teríamos que repetir 255 vezes o padrão aceito em cada posição : "[A-Z0-9]". Para resolver isso de uma forma mais elegante, a sintaxe para restrições do XSD fornece um recurso que nos permite estabelecer critérios para repetições em parte do padrão - ou nele todo, se isso for necessário.

Critérios para repetições são adicionados à direita do caracter - ou caracteres - que se quer repetir. Os símbolos válidos e seus significados são listados a seguir :
* Um asterisco indica que o(s) caractere(s) à esquerda dele pode(m) ser repetido(s) quantas vezes forem necessárias, incluindo zero. Isto é, o padrão associado ao asterisco pode ser omitido e ainda assim o valor será considerado válido. Por exemplo, aplicar o padrão abaixo a um campo num XML permitiria valores válidos desde um texto vazio até a ocorrência de quantas letras minúsculas, maiúsculas ou dígitos desejássemos:
<xs:pattern value="[azA-Z0-9]*" />

+ O sinal de "mais" sinaliza que o padrão à esquerda dele deve ser repetido uma ou mais vezes para que o valor no XML seja aceito. Assim, é obrigatório que o padrão ocorra ao menos uma vez. No exemplo abaixo, é obrigatória a ocorrência de ao menos um dígito mas não há limite máximo de quantidade de dígitos para um valor ser válido:
<xs:pattern value="[0-9]+" />

? Uma interrogação sinaliza que o padrão à esquerda é opcional, isto é, ele pode ser omitido mas se for incluído deve aparecer uma única vez. O padrão abaixo permite que se informe um dígito, uma letra X maiúscula ou que se omita o valor:
<xs:pattern value="[0-9X]?" />

{n} Especificar um número entre chaves determina uma quantidade exata de repetições do padrão. No caso do código de produto, poderíamos criar uma regra como a que segue para que tal código tenha obrigatoriamente 14 caracteres, que podem ser letras maiúsculas ou dígitos:
<xs:pattern value="[A-Z0-9]{14}" />

Esta sintaxe também permite fixar limites mínimos e máximos de repetição do padrão, bastando separar o valor desses limites por uma vírgula. Assim, informar {2,4} determina que o padrão deve ocorrer no mínimo 2 vezes e no máximo 4, enquanto informar {3,} obriga a ocorrência do padrão no mínimo 3 vezes, sem especificar um limite máximo.

Para associar uma regra de repetição a vários caracteres, declare o padrão desejado entre parênteses. Assim, todo o padrão interno terá que respeitar a regra de repetição. O padrão abaixo, por exemplo, dita que um valor para ser válido tem que ser composto por um ou mais pares de caracteres, o primeiro sendo um letra maiúscula e o segundo sendo um dígito :
<xs:pattern value="([A-Z][0-9])+" />

É importante ressaltar ainda que todas as regras descritas nos posts sobre a restrição do tipo pattern num XSD podem ser combinadas para gerar regras mais complexas. É possível até mesmo criar uma lista de padrões aceitos para um determinado valor, ligando as diversas regras com um caracter | (que significa "OU"). Quando houver uma lista fixa de valores aceitáveis, eles também podem ser declarados num pattern separados pelo caracter |:
<xs:pattern value="casado|solteiro|divorciado|viúvo" />

Um outro aspecto a se preocupar na criação de regras é o que fazer quando espaços em branco - incluindo quebras de linhas e tabulações - são informados no valor. O default é manter todos esses caracteres a aplicar também a eles as restrições de sequência estabelecidas. Mas, através da tag xs:whiteSpace, é possível fazer com que todos eles sejam substituidos por espaços em branco simples antes de aplicar a regra de sequência (valor replace) ou remover completamente esses espaços no começo e no fim do texto, além de juntar num único espaço as duplicidades que aparecerem no meio :
<xs:whiteSpace value="collapse" />
O xs:whiteSpace pode ser combinado na mesma restrição com outras tags, como o xs:pattern e o xs:minLength.

Mais Informações
Criando esquema para validar um xml - parte I, parte II, parte III e parte IV, Tratamento de restrições no XSD

8 de janeiro de 2011

Criando Esquema para validar um XML - parte IV

A flexibilidade das especificações para um XML feitas através de XSD pode chegar ao ponto de garantirmos que o valor de um determinado elemento no XML está de acordo com uma máscara previamente projetada. Um bom exemplo disso é a formatação do código do produto, campo que usei nos outros posts sobre esse assunto. Muitas empresas usam uma formatação inteligente para o código do produto, isto é, partes do código ajudam a identificar e classificar o produto de modo que é imprescindível que ele esteja formatado corretamente.

A tag no XSD responsável por essa parametrização é a xs:pattern, inserida dentro da tag xs:restriction exatamente como as outras restrições apresentadas até agora. Em xs:pattern podemos especificar a série de valores aceitos na tag correspondente do XML, montando caracter a caracter a máscara desejada. Basicamente, a posição de um novo caracter é marcada com um par abre-e-fecha colchetes envolvendo os valores aceitos. O trecho abaixo, por exemplo, exige que o código seja formado por 3 letras maiúsculas :
<xs:element name="codigo" >
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z][A-Z][A-Z]" />
</xs:restriction>
</xs:simpleType>
</xs:element>

Veja que para especificar a faixa de caracteres aceitos em cada posição eu usei um hífen separando o caracter inicial e o final da faixa : A-Z. Se quiser permitir também que letras minúsculas e algarismos sejam aceitos, basta inserir as faixas correspondentes no mesmo par de colchetes. Na tag pattern abaixo, o código continua a ter obrigatoriamente 3 caracteres mas o primeiro deles pode ser uma letra maiúscula, uma minúscula ou um algarismo enquanto nas duas posições finais apenas letras maiúsculas continuam a ser permitidas:
<xs:pattern value="[A-Za-z0-9][A-Z][A-Z]" />

Não é necessário qualquer separador para delimitar as faixas pois, como cada par de colchetes representa apenas um caracter no texto, a separação entre elas fica implícita. Com a restrição publicada acima, os códigos aBC ou 9ER são válidos mas não AbC, por exemplo. Por causa disso, poderemos chegar ao ponto de especificar uma lista de caracteres aceitos numa determinada posição do nosso código. Suponha que nosso código tenha que ser iniciado com uma das seguintes letras : A, C, M ou P, indicando uma classificação qualquer do produto. Imagine também que o código seja finalizado com um dígito verificador, totalizando 4 caracteres. Segue abaixo a montagem dessa restrição no XSD:
<xs:pattern value="[ACMP][A-Z][A-Z][0-9X]" />

O dígito verificador nesse exemplo pode ser qualquer algarismo ou a letra X maiúscula. Note que o XSD não é capaz de garantir que o dígito verificador informado tenha sido calculado corretamente. Validações desse tipo já caracterizam regras de negócio específicas e não são abordadas pelo XSD. O objetivo dele se restringe a garantir que um XML baseado nele esteja minimamente bem construído. É o mesmo tipo de situação da Nota Fiscal Eletrônica, onde a Receita disponibiliza um XSD com o básico da formação do XML mas algumas consistências têm que ser feitas fora desse escopo, cruzando informações com outros sistemas - por exemplo, para verificar se o CNPJ do emissor está mesmo ativo.

Embora eu só tenha usado exemplos com letras e números, qualquer caracter pode fazer parte de uma restrição pattern - até mesmo o hifen (-) e o fecha colchete (]). No entanto, como esses caracteres têm significado especial na sintaxe do XSD, use uma barra (\) para indicar que você quer usar esse caracter como parte da regra de restrição. A regra reproduzida abaixo mostra o exemplo anterior modificado para que um hifen seja usado para separar o dígito verificador do resto do código:
<xs:pattern value="[ACMP][A-Z][A-Z][\-][0-9X]" />

A própria barra é um caracter especial e, para usá-la numa regra, ela terá que ser incluída dobrada. Os seguintes códigos são válidos segundo a restrição acima: AER-8, CUR-0 e PAR-X.

No próximo post, abordo outras regras aplicáveis à criação de restrições, como tratamento de caracteres em branco, lista de valores fixos válidos e como repetir padrões para simplificar a montagem de regras.

Mais Informações
Criando esquema para validar um xml - parte I, parte II e parte III, Tratamento de restrições no XSD