SQL Server 2000   Visão Geral do Produto Da maneira como são conduzidos atualmente, os negócios requerem uma diferente abordagem na solução de questões relativas a bancos de dados. Performance, escalabilidade e confiabilidade são fatores essenciais, e o prazo de desenvolvimento de produtos baseados em bancos de dados é crítico. Além de possuir essas qualidades básicas, necessárias para as atuais corporações, o SQL proporciona agilidade no gerenciamento e análise de seus dados, permitindo que as empresas se adaptem de forma rápida e competente a novos ambientes em permanente transformação, conferindo-lhes uma sensível vantagem competitiva perante seu mercado. Do ponto de vista de gerenciamento de dados e análise, transformar dados brutos em inteligência corporativa e tirar o máximo proveito dos recursos da Internet tornaram-se fatores críticos para o sucesso dos negócios. Como solução completa de banco e análise de dados, o SQL Server 2000 abre um novo leque de possibilidades para o desenvolvimento rápido e ágil de uma nova geração de aplicações de negócios que poderão colocar sua empresa em posição de vanguarda na vantagem competitiva. O SQL Server 2000, ganhador de alguns dos maiores destaques mundiais em benchmarks de velocidade e escalabilidade é um produto de banco de dados totalmente desenhado para a Web, com total suporte à linguagem XML (Extensible Markup Language) e capacidade de fazer consultas na Internet, além do firewall, de forma inerente. Totalmente projetado para operar com a Internet. O SQL Server 2000 traz amplos recursos de programação de bancos de dados baseados em padrões da Web. Suporta de forma nativa a linguagem XML e a Internet possibilitando a fácil armazenagem e recuperação de dados em formato XML com stored procedures incorporadas ao produto. O usuário ou programador pode recorrer aos updategrams (diagramas de atualização) para inserir, atualizar ou apagar dados de forma muito simples. Fácil acesso a dados através da Web. Com o SQL Server 2000, pode-se utilizar o formato HTTP para enviar consultas ao banco de dados, realizar buscas no formato texto em documentos armazenados na base de dados e realizar pesquisas na Internet em linguagem natural. Poderosos e flexíveis recursos de análise baseada na Web. Todos os Serviços de Análise do SQL Server podem ser estendidos à Internet. O usuário pode acessar e manipular dados através de qualquer browser da Web. Altamente escalável e confiável. Com o SQL Server 2000 pode-se atingir níveis de escalabilidade e confiabilidade sem paralelo no mercado. Seus recursos de scale-up e scale-out respondem aos mais exigentes requisitos de comércio eletrônico e desenvolvimento de aplicações corporativas. Scale-up. O SQL Server 2000 utiliza todo o potencial dos sistemas de multiprocessamento simétrico (SMP). O SQL Server Enterprise Edition pode utilizar até 32 processadores e 64 GB de RAM. Scale-out. O recurso de scale-out distribui o banco de dados e a carga dos dados através dos diferentes servidores. Disponibilidade. O SQL Server 2000 adquire sua disponbilidade máxima através de um avançado clustering à prova de falhas, distribuição do log (log shipping) e através de novas estratégias de back-up. Desenvolvimento mais rápido. O SQL Server 2000 é o carro-chefe dos Servidores Corporativos da estratégia Microsoft .NET (Windows Server System) para o gerenciamento e análise de dados. O SQL Server 2000 inclui todas as ferramentas para acelerar o desenvolvimento, desde a fase conceitual até a distribuição final. Serviços de análise amplos e integrados. Com o SQL Server 2000, o usuário poderá desenvolver soluções de análise de grande envergadura empresarial, com ferramentas integradas que conferem valor efetivo aos dados. Com isso, pode-se criar novos processos empresariais que se baseiem nos resultados da análise de dados e reunir, com grande flexibilidade, conjuntos personalizados de resultados, a partir dos cálculos mais complexos. Alta velocidade no desenvolvimento, depuração e transformação de dados. O SQL Server 2000 traz sofisticados recursos para filtrar ou depurar consultas de forma interativa, mover e transformar, rapidamente, dados a partir de qualquer fonte, além de definir e utilizar funções como se elas estivessem incorporadas ao Transact-SQL. O desenvolvedor poderá construir e codificar aplicações de bancos de dados a partir de qualquer ferramenta do Visual Studio. Gerenciamento e afinação do banco de dados simplificados. Com o SQL Server, gerenciar um banco de dados de forma centralizada através de todos os recursos de uma organização tornou-se tarefa muito fácil. Mover e copiar bancos de dados entre computadores ou através de diferentes atividades corporativas pode ser realizado de forma on-line. Origem do Artigo: Site da Microsoft Brasil      O que é .NET   Introdução a Microsoft .NET NET é uma plataforma de software que conecta informações, sistemas, pessoas e dispositivos. A plataforma .NET conecta uma grande variedade de tecnologias de uso pessoal e de negócios, de telefones celulares a servidores corporativos, permitindo o acesso a informações importantes, onde e sempre que forem necessárias. Desenvolvido sobre os padrões de Web Services XML,.NET possibilita que sistemas e aplicativos, novos ou já existentes, conectem seus dados e transações independente do sistema operacional, tipo de computador ou de dispositivo móvel que sejam utilizados, ou que linguagem de programação tenha sido utilizada na sua criação. O .NET é um "ingrediente" presente em toda a linha de produtos Microsoft, oferecendo a capacidade de desenvolver, implementar, gerenciar e usar soluções conectadas através de Web Services XML, de maneira rápida, barata e segura. Essas soluções permitem uma integração mais rápida e ágil entre os negócios e o acesso a informações a qualquer hora, em qualquer lugar e em qualquer dispositivo. Conectando seu mundo A idéia fundamental por trás do Microsoft .NET é uma mudança de foco na informática, passando de um mundo de aplicativos, Web sites e dispositivos isolados para uma infinidade de computadores, dispositivos, transações e serviços que se conectam diretamente e trabalham em conjunto para fornecerem soluções mais amplas e ricas. As pessoas terão o controle sobre como, quando e que informações serão fornecidas a elas.Os computadores, sistemas e serviços serão capazes de colaborar e interoperar mutuamente em favor do usuário, e as empresas poderão oferecer seus produtos e serviços aos clientes certos, na hora certa, da forma certa, combinando processos de maneira muito mais granular do que é possível hoje. Origem do Artigo: Site da Microsoft Brasil      Os requisitos e o sucesso do seu projeto   Os requisitos e o sucesso do seu projeto Antes de começar de fato este artigo, quero passar algumas informações que colhi na minha pesquisa: · Mais de 30% dos projetos são cancelados antes de serem completados · Mais de 70% dos projetos falham na entrega das funcionalidades esperadas · A média de falhas de projetos estoura em mais de 189% do orçamento e extrapola em 222% do cronograma previsto · Os seguintes fatores ajudam: o Falta de informações dos usuários: 12,8% o Requisitos/especificações incompletos: 12,3% o Ausência de gerência de mudanças e especificações: 11,8% O propósito da gerência de requisitos é estabelecer um entendimento comum entre o cliente/usuário e a equipe de IT/desenvolvimento em relação aos requisitos do cliente/usuário. Parece simples mas não é! O desafio é tão grande que está presente até nas especificações do CMM (Capability Maturity Model). Além disto, estes requerimentos não ficam somente com a equipe de desenvolvimento: eles se propagam por todo o IT. Áreas como suporte, produção, telecom e outras são impactadas pelos requisitos que têm relação somente com aspectos internos destas áreas e que advêm dos requisitos básicos da aplicação em questão. Os pontos onde falhamos: 1. Uma pobre gerência de requisitos: Normalmente há a continuidade dos projetos mesmo com falhas nas informações dos usuários e sem a uma clara visão do problema que estamos tentando resolver 2. Falhas na gerência de mudanças: Mudanças nos requerimentos e outras modificações são inevitáveis, apesar de raramente rastrearmos e entendermos o impacto destas mudanças 3. Controle de qualidade pobre Temos fracas métricas de qualidade, pequeno conhecimento dos processos que afetam a qualidade, nenhum feedback para modificar o processo após testemunharmos os efeitos de uma estratégia de desenvolvimento particular (Web por exemplo) 4. Pequeno controle de cronogramas e custos Planejamento cuidadoso é a exceção enquanto expectativas irreais são a norma. Com base nestes dados acima, acho que temos tema suficiente para conversarmos. Vamos examinar o primeiro ponto: Uma das coisas mais comuns é a falta de entendimento entre os clientes e os analistas. Acho que todos já viram um desenho muito comum nas áreas de desenvolvimento que mostra as várias fases de um projeto ilustrado por uma árvore e um balanço. As perspectivas e a visão que os vários interessados no projeto têm nem sempre estão ajustadas. E para o pessoal de TI as coisas são um pouco mais difíceis porque o entendimento vai além de simplesmente entender qual é o negócio. Passa por verificar quais os impactos que a nova aplicação vai trazer para o ambiente já estabelecido, quais tecnologias serão envolvidas e etc... Temos então vários tipos de requisitos: funcionais, de teste, de performance, de ambiente, uma gama enorme que precisa ser gerenciada e distribuída entre a equipe de TI em suas respectivas responsabilidades. Passa a existir um grande problema que é gerenciar os múltiplos requisitos. Não importa se você usa papel, planilha, ou alguma ferramenta. O principal desafio é garantir os seguintes pontos: Você e os seus entenderam o que o cliente quer Você e os seus têm a mesma percepção do problema Você consegue compartilhar com outros os problemas que vem da solução proposta Você consegue acompanhar a execução e a implementação dos requisitos Você já pensou nisto? Como resolveu? Quais foram os problemas que enfrentou? Quanto custou? Vamos para o segundo ponto: Temos a certeza de que vão ocorrer mudanças, sejam elas advindas do negócio, dos problemas enfrentados para sua implementação, pela ausência de recursos ou outro motivo que os gerentes conseguem pensar sem fazer força. O problema em questão é como acompanhá-las. Mais uma vez os recursos para fazer o acompanhamento são vários, apesar de raramente se faz algumas análises importantes. Entender o que cada mudança significa para cada parte do seu projeto é difícil, mas calcular o impacto que elas trazem para o todo é quase impossível. A análise de impacto que cada mudança traz é uma atribuição da equipe envolvida no projeto e que normalmente não ocorre na sua total extensão. O que as pessoas fazem é calcular o tempo adicional ou alguns outros itens, sem ter também um rastreamento de que requisitos serão atingidos com as mudanças. E normalmente de forma manual... e sem que outras equipes de TI que vão suportar a futura aplicação tenham acesso às mudanças. Com isto se têm uma perda de produtividade enorme. Aqueles que receberam a solicitação de mudança, seja ela evolutiva, corretiva ou emergencial, precisam comunicar as decisões de mudanças rapidamente para os outros de forma que haja uma diminuição da perda de recursos gastos em re-trabalhos ou conflitos. E não somente no desenvolvimento mas no suporte, produção e etc... Este controle de mudanças traz também outros benefícios como começar a ter um histórico do projeto para servir de base de conhecimento para os próximos. Entender quanto tempo se investiu em determinada atividade motivada por uma mudança e melhorar as métricas gerais. Na realidade até ter algumas informações como qual é a carga de trabalho por elemento da equipe, quais são as solicitações em aberto, por prioridade, criticidade, tempo: bom uma infinidade de métricas e dados podem vir desta gerência, que é barata e efetiva. Quando chegamos a este ponto, entendemos melhor o item 3 lá atrás. Quais são as métricas de qualidade que você usa hoje nos seus projetos? A pergunta é dolorosa mas normalmente mostra uma realidade muito pior do que queremos ver. Normalmente temos muito poucas e confiáveis métricas para saber onde estamos e o quanto já fizemos. É normal termos um projeto que está 80% pronto mas só falta um pouquinho. Só que este pouquinho às vezes se torna outro projeto. Mostrei as estatísticas no início do texto. Gosto do que o Gartner chama de qualidade: Qualidade nos requisitos, no controle das mudanças e nos testes. Acho um tripé bastante claro e simples e que com ele dá para fazer várias análises em relação a se estabelecer métricas e pontos de controle. O desafio mais uma vez é como implementar este tripé. Até mesmo porque a maioria não tem histórico para saber quanto custo não ter. Nos meus contatos com os clientes há uma constatação de que está havendo uma maturidade em relação ao tripé descrito acima. Mais e mais empresas precisam ter diferenciais competitivos e rever seus processos de produção, seja no desenvolvimento seja na produção, são fatores de aumento de lucratividade ou diminuição de prejuízos. Há vários institutos tratando do assunto métricas e meu intento aqui é só realçar a importância de ser ter algum, mesmo que depois se mude. Criar a consciência da importância de se medir e ter histórico que foi feito. Independente das métricas que você pode escolher, é importante que você tenha ferramentas para fazer as duas gerências que trato desde o início deste texto: Requisitos e Mudanças Sempre falo sobre o custo de não se ter ou ter alguma coisa e sempre tento analisar este fato. Penso que você também pode fazer esta mesma análise. E acho que você pode chegar a conclusões incríveis. Agora vamos finalizar com os problemas de cronogramas e custos. Várias vezes somos simplesmente informados de que temos uma tarefa a realizar e que temos um determinado prazo para tal. Este prazo foi gerado a partir de um desejo, nem sempre realista. Não temos métricas ou históricos para antecipar a duração ou o custo de determinada atividade. Nossas informações são muitas vezes baseadas na experiência pessoal de cada um. Isto faz com que o nível de erro fique muito alto de acordo com as estatísticas do início do texto. Não podemos nos eximir de ter algum planejamento. Porém o como vamos fazê-lo é determinante para diminuir a margem de erros. Os riscos associados à falta de planejamento são      VB.NET - Otimização e Performance   Veremos nessa matéria, dicas e regras para melhorarmos a performance de nossas aplicações usando Visual Basic .NET. Quantas vezes nós já ouvimos falar que a linguagem X é mais rápida que a linguagem Y? Ou que a linguagem W é mais segura que a linguagem Z? Isso gera algumas discursões que nunca tem fim. Mas no fundo, o que acontece na maioria das vezes é que os programadores se esquecem que o quanto uma linguagem é segura ou performática depende quase sempre da forma como ela é usada e para que fim ela é usada. Para não causar polêmica, vou comparar duas linguagens da Microsoft, o VB6 e VB.NET. Quando o VB.NET chegou ao mercado, em 2001, vi muitos desenvolvedores dizendo que o VB6 era muito mais rápido do que o VB.NET, e cansei de responder perguntas em fóruns de discursão onde o cidadão até dava exemplo disso. Bem, na grande maioria das vezes eles estavam errados, o problema é que não dominavam a nova linguagem, menos ainda o ambiente de desenvolvimento, portanto o que faziam era simplesmente a conversão de VB6 -> VB.NET. E isso está bem longe de ser a melhor forma de se comparar performance. Quando refiz muito destes códigos, tchan, tchan, tchan, milagre! O código em VB.NET foi mais rápido. Por que? Veremos isso nas próximas linhas. Procure ter em mente a dobradinha: Performance X Segurança. Onde a segurança é o foco, a performance sai prejudicada e vice versa, embora ambas tenham sempre que andar juntas. Ache o meio termo. Como esse assunto é muito amplo, vou dividi-lo em partes: - Tipos de Dados - Declarações - Operações - Procedimentos - Outras Otimizações Tipos de Dados O tipo de dado que você escolhe para suas variáveis, propriedades, argumentos de procedimentos, variáveis de retorno, enfim, tudo isso afeta em muito a performance de sua aplicação. Value Type x Reference Type Tipos Value Type armazenam seus valores no seu próprio espaço de memória e são alocados na memória chamada Stack. Já os Reference Type guardam no seu espaço de memória apenas um ponteiro para o local onde o dado está armazenado, e que ficam em um espaço de memória chamado Heap. O gerenciamento da Heap é bem mais caro que o do Stack, devido à alocação de memória, acesso ao dado via referência, GC (Garbage Collection), etc. Isso significa que a escolha por um tipo Value Type na maioria das vezes é a melhor escolha. Contudo, os Value Types tem uma desvantagem: Ocupam mais espaço na memória. No final, a melhor opção é: Caso você não necessite da flexibilidade dos Reference Type, use os objeto do tipo Value type. Para saber mais: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec6_1.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec6_2.asp Early e Late Binding e o tipo Object Uma variável declarada como Object pode apontar (lembre-se do tipo Reference Type) para qualquer tipo de objeto. Essa flexibilidade tem um custo muito grande devido ao fato de esse tipo de variável ser sempre Late Bound. Quando o seu código acessa membros dessa variável, o CLR é obrigado a realizar checagem de tipo e procurar esse membro dentro do objeto em tempo de execução. Os objetos declarados como Early Bound tem uma performance significantemente superior aos Late bound. O seu código se torna mais legível e o número de erros em tempo de execução cai significativamente. Portanto, evite o uso de variáveis do tipo Object quando não for estritamente necessário. Para saber mais: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcn7/html/vaconEarlyLateBinding.asp Tamanho dos tipos de dados O tipo de dado mais eficiente é aquele que é usa o tamanho de dado nativo da plataforma. Ou seja, na plataforma de 32 bits o tipo de dados com 32 bits será o mais rápido. No .NET o tipo de dado que possui esse tamanho é o tipo Integer ou Int32. O próximo mais performático é o Long, e em seguida vem o Short e Byte. Pode não parecer, mas embora o tipo Integer seja maior do que o Short e o Byte, mesmo assim ele é mais rápido. Caso você queira usar o Short ou Byte e obter uma performance parecida com o do tipo Integer, desabilite a checagem de Overflow. É uma prática que eu desaconselho, principalmente por que hoje em dia memória já não é um grande problema. Caso você precise valores fracionários, a melhor escolha é o tipo Double, já que os processadores de ponto flutuante realizam suas operações em precisão dupla. Depois vem o tipo Single e Decimal. Box e Unboxing Boxing é um processamento extra que o CLR faz quando você trata um Value Type como um Reference Type. Isso é necessário quando, por exemplo: Você declara um tipo Integer e atribui a ele um tipo de variável Object ou passa-o para uma procedure que receba um Object como argumento. Neste caso, o CLR precisa converter a variável para o tipo Object. Se você subseqüentemente atribuir uma variável que sofreu boxing para uma variável Value Type, o CLR irá reverter isso. Esse processo chama-se Unboxing. Boxing e Unboxing, geram uma degradação de performance muito grande. Portanto se sua aplicação faz constantes operações como essa, prefira declarar o objeto inicialmente como Reference Type. Outra forma de evitar isso é definir a diretiva Option Strict On. Arrays Quanto menor a dimensão do array melhor a performance, então procure calcular bem o quanto você terá que usar, para não alocar espaço desnecessariamente. Jagged Arrays ( Array de Array ) são bem mais eficientes do que o array multidimensional, ou seja, A(6)(6) é mais eficiente do que A(6,6). Isto é devido ao fato de os Jagged Arrays sofrerem uma otimização para um array de uma dimenção. Só para constar, ele é aproximadamente 30% mais eficiente. ArrayList Essa classe é ideal para utilizar quando o array é dinâmico, ou seja, sobre muita alteração na sua dimensão. Usar ArrayList é muito mais performático do que usar o ReDim. A desvantagem do ArrayList é que os seus membros são do tipo Object, logo, Late Bound. Mas a vantagem sobre o uso do ReDim é tão grande que compensa essa desvantagem. Nessa primeira parte, vimos como o uso do tipo de dado correto pode tornar seu código mais eficiente. Na próxima parte iremos ver mais dicas sobre operações, procedimentos e outras otimizações. Até breve. Leonardo Bruno Lima - Microsoft MVP (Most Valuable Professional)      Web Services: um novo modelo de negócios para Internet   Um dos novos conceitos apresentados pela plataforma .NET são os chamados Web Services (ou Serviços Web). Mas o que são exatamente estes serviços? Para entender melhor este conceito é importante entender porque o mercado sentiu a necessidade de criá-lo. Muito se fala em computação distribuída, mas a realidade é que quando estamos trabalhando dentro de um ambiente controlado como as redes corporativas da nossa empresa, é possível criar aplicações que sejam compartilhadas por diversos servidores e desktops. Podemos inclusive escolher qual o melhor modelo de objetos para se construir tais aplicações, como o uso do COM+ da Microsoft, CORBA da OMG ou mesmo EJB (Enterprise JavaBeans) da Sun. O problema aparece quando pretendemos utilizar a infra-estrutura da Internet para executar remotamente tais objetos. Como trabalham em formato binário, estes objetos exigem uma porta de comunicação exclusiva, o que gera problemas quando precisamos atravessar um firewall, por exemplo. Por questões de segurança estas portas são fechadas, pois oferecem riscos de invasão à rede interna. A mesmo tempo uma linguagem para troca de dados entre aplicativos vinha ganhando grande aceitação do mercado, a linguagem XML. Com o objetivo de se tornar a "língua franca" da Internet, o XML oferece uma série de benefícios em relação aos formatos antigos. Para começar, além do próprio dado, ele leva ainda a descrição do mesmo. Por ser arquivo texto, pode ser interpretado em qualquer plataforma ou sistema operacional e não apresenta problemas quando encontra um firewall, já que não apresenta risco de segurança. Por último, e um padrão controlado por um órgão independente, o W3C (World Wide Web Consortium). Com tantos atributos é XML foi a base natural para criação do SOAP (Simple Object Application Protocol), modelo de objetos utilizados nos Web Services. As chamdas aos métodos públicos do objeto são chamados através de um arquivo XML, da mesma forma que a resposta a requisição também utiliza o mesmo formato. Mais dois padrões foram criados em cima destes, o WSDL (Web Service Description Language), uma espécie de contrato que descreve como o Web Service funciona (por sinal um arquivo XML), e o UDDI (Universal Defenition, Discovery Interface), a páginas amarelas de Web Services. Um serviço onde é possível cadastrar o seu serviço, categorizado, dentro dos serviços UDDI da Internet. Hoje este serviço é oferecido pela IBM, HP, SAP e Microsoft através do http://uddi.microsoft.com , mas novos serviços estão aparecendo a cada dia. Resumindo, os Web Services são componentes de software que são chamados a partir de outros aplicativos. São "páginas web" para outros computadores e não para seres humanos com as páginas HTML tradicionais. É a tecnologia que permite que computadores na Internet conversem entre si sem a intervenção direta dos usuários. Com toda esta infra-estrutura de tecnologia disponível, os Web Services estão se tornando uma nova opção de negócio para as empresas que planejam utilizar a Internet como meio de troca de informações. Os Web Services estão oferecendo uma nova proposição de negócios às empresas de tecnologia e abrindo um novo universo de oportunidades. Por: Leonardo Tolomelli - Gerente do Programa de Desenvolvedores da Microsoft Brasil