Microsoft .NET



Desenvolvedor	Microsoft
Lançamento	13 de Fevereiro de 2002
Versão estável	4.5 (12 de setembro de 2012; há 105 semanas e 6 dias ¹ )
Sistema operacional	98, 2000, XP, Vista, 7 e 8..
Licença	Freeware
Estado do desenvolvimento	Ativo
Página oficial	http://www.microsoft.com/net (em inglês)., acessado pela última vez há 115 semanas e 4 dias

Microsoft .NET (comumente conhecido por .NET Framework - em inglês: dotNet) é uma iniciativa da empresa Microsoft, que visa uma plataforma única para desenvolvimento e execução de sistemas e aplicações. Todo e qualquer código gerado para .NET pode ser executado em qualquer dispositivo que possua um framework de tal plataforma.

Com idéia semelhante à plataforma Java, o programador deixa de escrever código para um sistema ou dispositivo específico, e passa a escrever para a plataforma .NET.

Índice

Tecnicamente falando

O .NET Framework consiste basicamente em dois componentes principais, ou seja, ela é executada sobre uma Common Language Runtime - CLR (Ambiente de Execução Independente de Linguagem) interagindo com um Framework Class Library - FCL (Conjunto de Bibliotecas Unificadas). Esta CLR é capaz de executar, atualmente, mais de 33 diferentes linguagens de programação, interagindo entre si como se fossem uma única linguagem.²

Esta plataforma permite a execução, construção e desenvolvimento de Web Services (Aplicações Web) de forma integrada e unificada.

Arquitetura .NET

A plataforma .NET baseia-se em um dos principios utilizados na tecnologia Java (Just In Time Compiler - JIT), os programas desenvolvidos para ela são duplo-compilados (compilados duas vezes), uma na distribuição (gerando um código que é conhecido como "bytecodes") e outra na execução.

Um programa é escrito em qualquer das mais de trinta e três linguagens de programação disponíveis para a plataforma, o código fonte gerado pelo programador é então compilado pela linguagem escolhida gerando um código intermediário em uma linguagem chamada MSIL (Microsoft Intermediate Language).

Este novo código fonte gera um arquivo na linguagem de baixo nível Assembly, de acordo com o tipo de projeto:

EXE - Arquivos Executáveis, Programas
DLL - Biblioteca de Funções
ASPX - Página Web
ASMX - Web Service

No momento da execução do programa ele é novamente compilado, desta vez pelo compilador JIT, de acordo com a utilização do programa, por exemplo: Temos um Web Site desenvolvido em ASP.NET, ao entrar pela primeira vez em uma página o JIT irá compila-la, nas outras vezes que algum outro usuário acessar esta página, ele usará esta compilação.

Também é possível, através de ferramentas específicas, "pré-compilar" o código para que não se tenha o custo da compilação JIT durante a execução.

O fato desta arquitetura utilizar a MSIL gera uma possibilidade pouco desejada entre os criadores de software que é a de fazer a "engenharia reversa", ou seja, a partir de um código compilado, recuperar o código original. Isto não é uma idéia agradável para as empresas que sobrevivem da venda de softwares produzidos nesta plataforma.

Por causa disso, existem ferramentas que "ofuscam" o código MSIL, trocando nomes de variáveis, métodos, interfaces e etc para dificultar o trabalho de quem tentar uma engenharia reversa no mesmo.

.NET Framework 4

O .NET Framework 4 veio para melhorar, alguns pontos do Framework anterior, como por exemplo:

Aplicações legadas podem continuar rodando no release anterior do Framework, para não haver problemas de compatibilidade
Possui Background Garbage Collection
Tem suporte para aplicações Multitouch
Consegue fazer uso das novas funcionalidades do Windows 7

Se você é um desenvolvedor Web, algumas das melhorias que são encontradas na nova versão do Framework:

Pré-carregamento da sua aplicação
A utilização de Routing no ASP.NET para Web Forms
Controle/Redução de ViewState
A utilização do pattern MVC

A maneira mais simples de se ter o .NET Framework 4 instalado é utilizando o Web Platform Installer da Microsoft, também chamado de Web PI.

Referências

Microsoft. Microsoft TI & Negócios - Matérias - Microsoft inova e moderniza o desenvolvimento de aplicativos com Visual Studio 2012 (em Português). Página visitada em 24 de janeiro de 2013.
.NET Framework

Ver também

Web service

Origem: Wikipédia, a enciclopédia livre.

(Redirecionado de Web Service)

Web service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.

Para as empresas, os Web services podem trazer agilidade para os processos e eficiência na comunicação entre cadeias de produção ou de logística. Toda e qualquer comunicação entre sistemas passa a ser dinâmica e principalmente segura, pois não há intervenção humana.

Essencialmente, o Web Service faz com que os recursos da aplicação do software estejam disponíveis sobre a rede de uma forma normalizada. Outras tecnologias fazem a mesma coisa, como por exemplo, os browsers da Internet acessam às páginas Web disponíveis usando por norma as tecnologias da Internet, HTTP e HTML. No entanto, estas tecnologias não são bem sucedidas na comunicação e integração de aplicações. Existe uma grande motivação sobre a tecnologia Web Service pois possibilita que diferentes aplicações comuniquem - se entre si e utilizem recursos diferentes.

Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efectuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Por outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Service.

Os Web Services são identificados por um URI (Uniform Resource Identifier), descritos e definidos usando XML (Extensible Markup Language). Um dos motivos que tornam os Web Services atractivos é o facto deste modelo ser baseado em tecnologias standards, em particular XML e HTTP (Hypertext Transfer Protocol). Os Web Services são utilizados para disponibilizar serviços interactivos na Web, podendo ser acessados por outras aplicações usando, por exemplo, o protocolo SOAP (Simple Object Access Protocol).

O objectivo dos Web Services é a comunicação de aplicações através da Internet. Esta comunicação é realizada com intuito de facilitar a EAI (Enterprise Application Integration) que significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre a informação que circula numa organização nas diferentes aplicações como, por exemplo, o comércio electrónico com os seus clientes e seus fornecedores. Esta interação constitui o sistema de informação de uma empresa. E para além da interoperabilidade entre as aplicações, a EAI permite definir um workflow entre as aplicações e pode constituir uma alternativa aos ERP (Enterprise Resource Planning). Com um workflow é possível optimizar e controlar processos e tarefas de uma determinada organização.

Índice

7 Iniciativas em curso

7.1 Contribuição das empresas

8 Evolução dos Web Services

Padrão

O W3C, OASIS são as instituições responsáveis pela padronização dos Web Services. Empresas como IBM e Microsoft, duas das maiores do setor de tecnologia, apoiam o desenvolvimento deste padrão.

Segundo o W3C (World Wide Web Consortium) um Web Service define-se como: um sistema de software projectado para suportar a interoperabilidade entre máquinas sobre rede.

Tem uma relação descritiva num formato machine-processable, especificamente WSDL (Webservice Description Language).

Outros sistemas interagem com o Web Service usando as mensagens SOAP, tipicamente sobre HTTP com XML na junção com outros standards da Web.

Tecnologias

As bases para a construção de um Web service são os padrões XML e SOAP. O transporte dos dados é realizado normalmente via protocolo HTTP ou HTTPS para conexões seguras (o padrão não determina o protocolo de transporte). Os dados são transferidos no formato XML, encapsulados pelo protocolo SOAP.

Segurança

Muitas empresas temiam, no passado, prover funcionalidades na Internet devido ao medo de expor seus dados. Mas com advento dos Web Services elas podem publicar serviços de forma simples e que são totalmente isolados da base de dados.

A segurança dos Web Services é um dos pontos fracos desta tecnologia. O problema não é a falta de mecanismos de segurança mas sim a falta de consenso em qual deve ser o mecanismo a ser adaptado pela tecnologia Web Service, As questões mais relevantes na segurança são as seguintes:

Autenticidade (ter a certeza que uma transacção do Web Service ocorreu entre o servidor e seu cliente;
Privacidade (todas as mensagens trocadas entre o servidor e o cliente não são interceptadas por uma pessoa não autorizada);
Integridade (as mensagens enviadas tanto pelo servidor ao cliente, como o contrário, devem permanecer inalteradas).

A seguir, descrevem-se os principais mecanismos de segurança.

SSL

O SSL (Secure Socket Layer) [Netscape 1996] quando aplicado a pequenos dispositivos oferece autenticação, integridade de dados e privacidade de serviços. Assim, tornou-se possível enviar informação confidencial utilizando um mecanismo de segurança SSL sob HTTP também conhecido como HTTPS (Hypertext Transfer Protocol Secure). Este mecanismo protege informações confidenciais e é fácil de ser configurado. Tem como desvantagem ser mais lento do que as transacções HTTP não cifradas pelo que não é adequado para taxas de transferências de dados elevadas. Por ser um mecanismo de proteção no nível de transporte, apresenta restrições para ser aplicado em aplicações webservices, pois o SSL não permite criptografia de parte da informação nem o uso de sessões seguras entre mais de duas partes, uma vez que seu funcionamento se baseia em uma arquitetura de transporte fim-a-fim.

Xml signature

A XML Signature [IETF e W3C 2000] é uma iniciativa conjunta da IETF (Internet Engineering Task Force) e do W3C para especificar uma sintaxe XML e regras de processamento para criação e representação de assinatura digital. As vantagens na utilização da XML Signature, ao contrário de outras normas de assinaturas digitais, estão baseadas na independência da linguagem de programação, fácil interpretação humana e independência do fabricante. Esta tecnologia também permite assinar digitalmente subconjuntos de um documento XML.

Xml encryption

A XML Encryption [IETF e W3C 2002] especifica um processo para cifra de dados e sua representação em formato XML. Os dados podem ser dados arbitrários (incluindo um documento XML), elementos XML ou conteúdos de elementos XML. Um documento XML que utiliza a XML Encryption pode ser visto por qualquer utilizador, mas apenas o proprietário da chave de descodificação conseguirá compreender o conteúdo codificado.

Ws-security

O WS-Security (Web Services Security) é uma iniciativa conjunta de empresas como Microsoft, IBM e Verisign destinada ao uso da XML-Signature e da XML-Encryption para fornecer segurança às mensagens SOAP. O WS-Security é um esforço destinado a fazer com que os Web Services trabalhem melhor em um ambiente global. O WS-Security também inclui alguns importantes componentes como encaminhamento, confiança e tratamento de transações.

Saml

O SAML (Security Assertion Markup Language) [OASIS 2001] é um padrão emergente para a troca de informação sobre autenticação e autorização. O SAML soluciona um importante problema para as aplicações da próxima geração, que é a possibilidade de utilizadores transportarem seus direitos entre diferentes Web Services. Isto é importante para aplicações que tencionam integrar um número de Web Services para formar uma aplicação unificada.

Limitações associados aos Web Services

Apesar da sua grande popularidade ^[^{carece de
fontes}^] e relativa simplicidade ^[^{carece de
fontes}^], o SOAP tem várias limitações, que por sua vez afetam os Web Services diretamente, por dependerem de tais recursos.

As limitações são descritas em seguida:

Segurança e privacidade — nenhuma das versões do SOAP define qualquer tipo de segurança. Isto é devido ao SOAP utilizar HTTP, mas para implementar mecanismos de segurança no nível de transporte pode utilizar o protocolo SSL no HTTP (também conhecido como HTTPS) para garantir a confidencialidade, a integridade e a autenticação do cliente, do servidor e da comunicação cifrada. Como não existe um suporte para segurança, que inclui a privacidade, nas normas que compõem os Web Services, tem levado cada projeto a procurar diferentes soluções para resolver o problema da segurança o que se torna incompatível com a promessa de implementar uma normalização a nível global.
Mensagens e encaminhamento — para suportar as funcionalidades das mensagens assíncronas tradicionais
Qualidade de serviço e confiabilidade — para garantir tempos de resposta e detectar exceções
Processamento transaccional — para suportar comunicação transaccional, para associar essa comunicação transaccional com as transacções locais e para participar em transacções distribuídas
Gestão — para controlar o estado e comportamento dos Web Services
Desempenho — para optimizar a execução dos Web Services que tem implicações ao nível do desenho das aplicações, chamadas remotas, características da rede e armazenamento/processamento dos documentos
Interoperabilidade — suportar a interoperação sem problemas é o grande objetivo dos Web Services e do SOAP, ou seja, fornecerem uma plataforma de integração entre aplicações e diferentes linguagens e implementados em qualquer sistema operacional.

Assim, esta tecnologia seria uma tecnologia normalizada, mas, no entanto, existem algumas incompatibilidades entre os WSDL´s disponibilizados entre os diferentes fornecedores. A exemplo da especificação, ao que refere-se ao binding, podem ser implementados de diferentes maneiras, causando um conflito de como fazer a interpretação. Alguns fazem tal qual a especificação, relacionando e declarando todos os métodos e objetos complexos de forma explícita, enquantos outros fornecedores não o fazem desta forma, tornando-os assim, incompatíveis.

Integração de sistemas

Muitas pessoas consideram que os Web services corrigem um grande problema da informática: a falta de integração de sistemas.

Os Web services permitem que a integração de sistemas seja realizada de maneira compreensível, reutilizável e padronizada.

É uma tentativa de organizar um cenário cercado por uma grande variedade de diferentes aplicativos, fornecedores e plataformas.

Tecnologias Utilizadas

Para a representação e estruturação dos dados nas mensagens recebidas/enviadas é utilizado o XML (eXtensible Markup Language). As chamadas às operações, incluindo os parâmetros de entrada/saída, são codificadas no protocolo SOAP (Simple Object Access Protocol, baseado em XML). Os serviços (operações, mensagens, parâmetros, etc.) são descritos usando a linguagem WSDL (Web Services Description Language). O processo de publicação/pesquisa/descoberta de Web Services utiliza o protocolo UDDI (Universal Description, Discovery and Integration).

XML

Extensible Markup Language (XML) é a base em que os Web Services são construídos. O XML fornece a descrição, o armazenamento, o formato da transmissão para trocar os dados através dos Web Services e também para criar tecnologias Web Services para a troca dos dados.

A sintaxe de XML usada nas tecnologias dos Web Services especifica como os dados são representados genericamente, define como e com que qualidades de serviço os dados são transmitidos, pormenoriza como os serviços são publicados e descobertos. Os Web Services decodificam as várias partes de XML para interagir com as várias aplicações.

SOAP

O SOAP (Simple Object Access Protocol) baseia-se numa invocação remota de um método e para tal necessita especificar o endereço do componente, o nome do método e os argumentos para esse método. Estes dados são formatados em XML com determinadas regras e enviados normalmente por HTTP para esse componente. Não define ou impõe qualquer semântica, quer seja o modelo de programação, quer seja a semântica específica da implementação. Este aspecto é extremamente importante, pois permite que quer o serviço, quer o cliente que invoca o serviço sejam aplicações desenvolvidas sobre diferentes linguagens de programação. Por esta razão, o SOAP tornou-se uma norma aceita para se utilizar com Web Services, uma tecnologia construída com base em XML e HTTP. Desta forma, pretende-se garantir a interoperabilidade e intercomunicação entre diferentes sistemas, através da utilização da linguagem XML e do mecanismo de transporte HTTP ou outro como, por exemplo, SMTP. O SOAP permite que os documentos XML de envio e de recepção sobre a Web suportem um protocolo comum de transferência de dados para uma comunicação de rede eficaz, ou seja, o SOAP providencia o transporte de dados para os Web Services.

Em relação a Web, o SOAP é um protocolo de RPC que funciona sobre HTTP (ou SMTP, ou outro) de forma a ultrapassar as restrições de segurança/firewalls normalmente impostas aos sistemas clássicos de RPC (RMI, DCOM, CORBA/IIOP) suportando mensagens XML. Em vez de usar HTTP para pedir uma página HTML para ser visualizada num browser, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma resposta, se existir, através da resposta do HTTP. Para assegurar correctamente a transmissão da mensagem de XML, o servidor de HTTP, tais como Apache ou IIS (Microsoft Internet Information Server), recebe mensagens SOAP e deve validar e compreender o formato do documento XML definido na especificação SOAP v1.1.

WSDL

É a sigla de Web Services Description Language, padrão baseado em XML para descrever o serviço como no COM, onde ele traz os métodos do Web Service. Funciona como uma espécie de "TypeLibrary" do Web Service, além de ser usado para a validação das chamadas dos métodos.

O WSDL (Web Services Description Language) é uma especificação desenvolvida pelo W3C que permite descrever os Web Services segundo um formato XML.

O WSDL é extensível para permitir a descrição dos serviços e suas mensagens, independentemente dos formatos de mensagem e dos protocolos de rede que sejam usados. No entanto, é comum usar-se o MIME (Multipurpose Internet Mail Extensions) e o HTtp://SOAP.

O WSDL descreve os serviços disponibilizados à rede através de uma semântica XML, este providencia a documentação necessária para se chamar um sistema distribuído e o procedimento necessário para que esta comunicação se estabeleça. Enquanto que o SOAP especifica a comunicação entre um cliente e um servidor, o WSDL descreve os serviços oferecidos.

UDDI

Protocolo desenvolvido para a organização e registro de Web Services.

O UDDI (Universal Description Discovery and Integration) é uma iniciativa em desenvolvimento no âmbito do consórcio industrial UDDI promovido originalmente pela IBM, Microsoft e Arriba, com objectivo de acelerar a interoperabilidade e utilização dos Web Services, pela proposta de um serviço de registro de nomes de organizações e de descrição do serviço. UDDI nada mais é do que um serviço de diretório onde empresas podem registrar (publicar) e buscar (descobrir) por serviços Web (Web Services).

Um registro UDDI contém três tipos de informação:

informações gerais de cada organização, tais como o nome, endereço e contatos;
informações de organizações e serviços por categorias de negócios;
informações técnicas sobre os serviços providenciados pelas organizações.

O UDDI providencia três funções principais, conhecidas como publicação, descoberta e ligação:

1) publicação: permite que uma organização divulgue o(s) seu(s) serviço(s); 2) descoberta: permite que o cliente do serviço, procure e encontre um determinado serviço; 3) ligação (bind): permite que o cliente do serviço, possa estabelecer a ligação e interagir com o serviço.

WS-i

É o consórcio que garante a integração entre os Web Services para garantir sempre que os Web Services possam "conversar entre-si".

Iniciativas em curso

O sucesso que os Web Services possam vir a apresentar passa necessariamente pela vontade da indústria, pela partilha e abertura dos processos de normalização e das próprias especificações daí resultantes. Parte significativa desse processo tem sido desenvolvida no âmbito do W3C. No entanto, dever-se-á também referir outros esforços e consórcios que têm vindo a ser desenvolvidos, designadamente o UDDI, o ebXML, ou o XML/EDI. Por exemplo, o ebXML é um esforço patrocinado pela UN/CEFACT e pela OASIS, cujo objectivo é a produção de um conjunto de especificações para permitir colaborações de negócio electrónico. O standard ebXML pode ser visto como uma extensão às funcionalidades de descrição, publicação e descoberta de serviços (definidas no âmbito do UDDI), ao tratar os seguintes aspectos: como especificar os processos de negócio; como identificar os Web Services participantes e respectivas colaborações; ou, que padrões de negociação existem na colaboração entre os participantes. Estes aspectos, são tratados nomeadamente nas seguintes especificações:

1) Esquemas para especificação de processos de negócio, BPSS (business process specification schema); 2) Acordos de protocolos de colaboração, CPA (collaboration protocol agreement); 3) Ou perfis de protocolos de colaboração, CPP (collaboration protocol profile).

Contribuição das empresas

As principais empresas, para além de promoverem e participarem activamente nos vários consórcios de normalização, têm vindo a incorporar nas suas próprias infra-estruturas de desenvolvimento e suporte de aplicações implementações das normas ligadas aos Web Services. Entre outras, merece referência a plataforma da Microsoft, ".Net", da Sun, "Java ONE (Open Net Environment)", da Hewlett-Packard, "e-speak" e da IBM, "IBM Web Services".

Evolução dos Web Services

Novos Modelos de Negócio

Só o futuro dirá quem tem razão: se os cépticos ou conservadores, se os que arriscam e concretizam a sua visão. Com o conceito dos Web Services talvez o mais importante nem seja a tecnologia em si, mas toda uma discussão à volta dos factores económico-políticos que este paradigma poderá suscitar, bem como os modelos de negócio que poderão emergir.

Parece natural a emersão de novos portais, não para as pessoas consultarem e usarem, mas para as aplicações, i.e., para os serviços se registarem/publicarem de modo a tornarem-se conhecidos, descobertos e usados. Esses portais de serviços (tecnicamente consiste em serviços de registos UDDI e/ou ebXML) poderão ser definidos a nível global, regional, para domínios de negócio horizontais ou verticais.

Novos Requisitos Tecnológicos

No entanto e naturalmente, novos problemas e requisitos tecnológicos são colocados com o conceito dos Web Services. Desde logo, ao nível da modelação destes serviços e dos processos de negócio em que aqueles participam. Aspectos como a composição de serviços, coordenação de fluxos de trabalho, identificação e privacidade, segurança, negociação, contratos e pagamentos, tratamento de excepções, categorização e taxonomias de serviços, etc., deverão ser adequadamente investigados e tratados de forma que este paradigma possa vir a apresentar um largo consenso e sucesso.

Vantagens e Desvantagens

Os Web Services são modelos que surgiram para o desenvolvimento de aplicações típicas de negócio electrónico, envolvendo e suportando o estabelecimento da colaboração e negociação de forma aberta, distribuída e dinâmica entre distintos parceiros.

Os Web Services podem no futuro representar um sucesso significativo por causa de existir um esforço significativo, por parte da maioria dos parceiros industriais, na normalização das tecnologias envolvidas.

As tecnologias subjacentes aos Web Services (tais como HTTP, SOAP, WSDL, UDDI, XML) são abertas, amplamente divulgadas e consensuais. Por outro lado, existe potencial para haver uma real independência das linguagens de programação (Java, C++, VB, Delphi, C#), das arquitecturas de computadores e sistemas operativos, o que permite uma evolução mais suave e económica para este modelo computacional.

No entanto, existe críticas que demonstram medos ou falsas expectativas que os investimentos em Web Services podem suscitar. Uma dessas críticas diz respeito ao facto do SOAP é menos eficiente do que os sistemas de RPC existentes. Por exemplo, as mensagens (com os respectivos envelopes e descrição de tipos) trocadas entre as partes são descritas em formato de texto/XML enquanto que nos sistemas clássicos de RPC são trocadas em formato binário.

No entanto, esta desvantagem é compensada significativamente pela facilidade de interoperação entre os serviços, sem os problemas conhecidos de segurança/firewalls, e pela facilidade de se esconder os detalhes proprietários das infra-estruturas de suporte..

quarta-feira, 24 de setembro de 2014

Microsoft.Net