Projeto Astoria.
Publicado em: 9 de janeiro de 2008
Por Pablo Castro
Resumo: O projeto Astoria produz um conjunto de padrões e também uma infra-estrutura concreta para a criação e o consumo de serviços de dados utilizando tecnologias da web. Este artigo explora a mudança dos modernos aplicativos e serviços web centralizados e o papel que o Astoria pode desempenhar nessas novas arquiteturas.
Os dados tornam-se cada vez mais disponíveis, como um elemento de primeira classe na web. A proliferação de novos tipos de aplicativos dirigidos a dados, como os mashups, indica claramente que a ampla disponibilidade de dados auto-suficientes, independentes de qualquer IU, está mudando a forma com que os sistemas são construídos e, também, o aproveitamento dos dados. Mais ainda, tecnologias como a do Asynchronous JavaScript and XML (AJAX) e do Microsoft Silverlight estão introduzindo a necessidade de mecanismos para a troca de dados independentemente da apresentação de informações para dar suporte a experiências de usuário altamente interativas.
O projeto Astoria oferece a arquitetos e desenvolvedores um conjunto de padrões para a interação com serviços de dados sobre HTTP utilizando formatos simples como POX (Plain Old XML) e JavaScript Object Notation (JSON). O cumprimento à risca do protocolo HTTP resulta em excelente integração com a infra-estrutura existente de web, da autenticação a proxies e cache. Além dos padrões e formatos, fornecemos uma implementação concreta que pode fazer surgir automaticamente um esquema de modelo de dados de entidades (EMD - Entity Data Model) ou outras fontes de dados por meio da interface HTTP.
Ainda que a infra-estrutura de software oferecida pelo Astoria possa ser uma peça útil do quebra-cabeça para a construção de novos aplicativos e serviços web, é apenas uma peça. Outros elementos desses aplicativos precisam ser organizados para permitir a interação com dados pela web.
Neste artigo, tratarei dos aspectos arquiteturais que sofrem o impacto das abordagens modernas do desenvolvimento de aplicativos preparados para web, com enfoque em como os serviços de dados se integram no quadro.
Nesta página
Separando os dados da apresentação
Interfaces de dados flexíveis
Interação com dados da camada de apresentação
Introdução à lógica do negócio
Extensibilidade e fontes de dados alternativas
Cenários de implantação: aplicações e serviços
Segurança
Notas de encerramento: escopo e planos do projeto Astoria
Referências
Sobre o autor
Separando os dados da apresentação
A nova geração de aplicativos web utiliza tecnologias como AJAX, Microsoft Silverlight ou outras infra-estruturas de apresentação rica. Uma característica comum de todas essas tecnologias é que elas impõem uma mudança com respeito à forma com que os aplicativos web são construídos.
A Figura 1 compara o fluxo de conteúdo nos tipos tradicional e moderno de aplicativos web. Aplicativos web tradicionais dirigidos a dados compreendem, tipicamente, um conjunto de páginas ou scripts do lado do servidor, executado quando chega uma solicitação; durante o processo, as páginas ou scripts executam algumas consultas ao banco de dados e, então, processam o HTML que contém informações de apresentação e dados nele incorporados.
Um aplicativo baseado em AJAX ou Silverlight não segue esse modelo de interação. As informações de apresentação são despachadas para o navegador web com o código para acionar a IU, mas sem os dados verdadeiros. Essas informações de apresentação são, em geral, uma combinação de aplicativos HTML, Cascading Style Sheets (CSS), JavaScript for AJAX e Extensible Application Markup Language (XAML)/ DLLs para Silverlight. Depois que o código está ativo e em execução no cliente, a IU inicial é apresentada e os dados são recuperados na medida em que o usuário interage com a interface.
.jpg "Bb906063.journal_13_cap03_01(pt-br,MSDN.10).jpg")
Curiosamente, este novo ciclo de tecnologias está agindo como uma função de força para transferir a organização do aplicativo na direção de uma meta comum em muitas arquiteturas de aplicativos: separação rígida entre dados e apresentação.
Pela perspectiva do servidor, apresentar os elementos da IU é relativamente fácil. Na maioria das vezes, são simples recursos de arquivo no servidor, como arquivos HTML ou CSS e arquivos de mídia. Apresentar os dados é outra história. Até agora, a interação com dados era algo que acontecia entre o servidor web e o servidor do banco de dados; não havia necessidade de expor pontos de entrada acessíveis do código, executado em toda a web, em um navegador web ou algum outro agente de software. É neste ponto que entra o projeto Astoria.
Interfaces de dados flexíveis
Há várias formas de expor dados aos clientes que os consumirão pela web. Uma abordagem, possibilitada pelas tecnologias existentes, é usar uma conduta similar à chamada de procedimento remoto (RPC - Remote Procedure Call): as funções são expostas por meio da interface como os Web Services (por exemplo, interface baseada no protocolo SOAP ou uma convenção simples baseada em UTI para chamar métodos e parâmetros de transferência). O Microsoft Visual Studio oferece um conjunto de ferramentas comprovado, que facilita criar e consumir interfaces construídas dessa forma. O conjunto de ferramentas do ASP.NET AJAX leva isso para o próximo nível, permitindo que Web Services criados com o Visual Studio trabalhem com clientes AJAX.
O principal problema desta abordagem é a flexibilidade. Se a interação com dados acontece apenas por meio de pontos de entrada fixos e predefinidos, qualquer cenário novo ou variação dos existentes, com dados pouco diferentes, exigirá, tipicamente, a criação de novos pontos de entrada. Ainda que este nível de controle seja conveniente em determinadas ocasiões, na maioria dos casos, maior flexibilidade aumentará a produtividade do desenvolvimento e contribuirá para um aplicativo mais dinâmico.
O projeto Astoria apresenta uma alternativa à abordagem RPC, baseada na semântica simples do HTTP. O Astoria adota uma definição de esquema que descreve cada uma das entidades com as quais o seu aplicativo lida, mais as associações entre entidades expondo-as sobre uma interface HTTP. Cada entidade pode ser endereçável com um identificador de recurso uniforme (URI - Uniform Resource Identifier) e a convenção do URI permite aos aplicativos atravessar as associações entre entidades, pesquisar entidades e executar outras operações normalmente exigidas com dados.
A definição do esquema utilizado pelo Astoria é o esquema de modelo de dados de entidades (EMD - Entity Data Model), diretamente compatível com o ADO.NET Entity Framework. O Entity Framework também inclui um robusto mecanismo de mapeamento que permite aos desenvolvedores mapear o esquema EDM em um banco de dados relacional para o armazenamento efetivo.
Para demonstrar a interação com os serviços do Astoria, utilizarei um exemplo com base no conhecido banco de dados Northwind. É possível configurar um serviço de dados sobre o Northwind criando um aplicativo ASP.NET, importando o esquema Northwind do banco de dados em um esquema EDM, por meio do assistente ADM e, depois, criar um serviço de dados Astoria voltado para aquele esquema EDM.
As etapas detalhadas para a criação de serviços de dados Astoria, assim como farta documentação sobre o URI Astoria e os formatos de carga podem ser encontrados no documento “Using Microsoft Codename Astoria”, disponível no website Astoria no endereço http://astoria.mslivelabs.com.
Depois que o serviço estiver ativo e operacional, os URIs poderão ser utilizados para examinar os recursos expostos pela interface de dados.
Os exemplos a seguir utilizam o serviço experimental do Astoria on-line que hospeda alguns serviços de dados read-only. Por exemplo:
http://astoria.sandbox.live.com/northwind/northwind.rs e/Customers
retornaria todos os recursos do container recurso de clientes. No formato XML-padrão, teria esta aparência:
<DataService xml:base=”http://astoria.sandbox.live. com/northwind/northwind.rse”> <Customers> <Customer uri=”Customers[ALFKI]”> <CustomerID>ALFKI</CustomerID> <CompanyName>Alfreds Futterkiste</CompanyName> <ContactName>Maria Anders</ContactName> <ContactTitle>Sales Representative</ContactTitle> <Address>Obere Str. 57</Address> <City>Berlin</City> <Region /> <PostalCode>12209</PostalCode> <Country>Germany</Country> <Phone>030-0074321</Phone> <Fax>030-0076545</Fax> <Orders href=”Customers[ALFKI]/Orders” /> </Customer> <Customer uri=”Customers[ANATR]”> ...properties </Customer> ...more customer entries </Customers> </DataService>
Pode-se também apontar para uma entidade específica utilizando estas chaves:
http://astoria.sandbox.live.com/northwind/northwind.rs e/Customers[ALFKI]
retornaria um recurso de cliente específico; novamente, utilizando o formato XML no exemplo:
<DataService xml:base=”http://astoria.sandbox.live. com/northwind/northwind.rse”> <Customers> <Customer uri=”Customers[ALFKI]”> <CustomerID>ALFKI</CustomerID> <CompanyName>Alfreds Futterkiste</CompanyName> <ContactName>Maria Anders</ContactName> <ContactTitle>Sales Representative</ContactTitle> <Address>Obere Str. 57</Address> <City>Berlin</City> <Region /> <PostalCode>12209</PostalCode> <Country>Germany</Country> <Phone>030-0074321</Phone> <Fax>030-0076545</Fax> <Orders href=”Customers[ALFKI]/Orders” /> </Customer> </Customers> </DataService>
Se o URI apontar para um recurso específico, como o que acabamos de discutir, é possível não apenas recuperar o recurso utilizando um comando HTTP GET, mas também atualizá-lo, utilizando HTTP PUT, ou excluí-lo utilizando HTTP DELETE.
Como a descrição do esquema fornecido ao Astoria inclui associações entre as entidades, estas podem também ser aproveitadas na interface HTTP. Continuando com o exemplo, se cada recurso de cliente estiver associado a um conjunto de recursos de pedidos, o seguinte URI representará o conjunto de pedidos relacionado a um determinado cliente:
http://astoria.sandbox.live.com/northwind/northwind.rs e/Customers[ALFKI]/Orders
Além de ser capaz de apontar para recursos específicos e listar os recursos de um container, também é possível filtrar, ordenar e paginar os dados para facilitar a criação de IUs sobre o serviço de dados. Por exemplo, para listar todos os recursos de clientes da cidade de Londres, ordenados pelo nome do contato, o aplicativo pode usar este URI:
O formato real do URI do Astoria ainda pode estar sujeito a mudanças, mas a semântica e as capacidades devem permanecer relativamente estáveis.
Em qualquer dos casos, os dados são trocados em formatos simples como XML ou JSON. O formato real pode ser controlado pelo cliente- agente utilizando negociação do tipo de conteúdo HTTP normal. Os dados são codificados como recursos que simplesmente mapeiam propriedades de entidades EDM em elementos XML ou propriedades JSON, as quais estão vinculadas por hyperlinks a outros recursos com os quais estão associadas. Por exemplo, o URI do exemplo anterior:
http://astoria.sandbox.live.com/northwind/northwind.rs e/Customers[ALFKI]
resultaria na seguinte resposta (em XML):
<DataService xml:base=”http://astoria.sandbox.live. com/northwind/northwind.rse”> <Customers> <Customer uri=”Customers[ALFKI]”> <CustomerID>ALFKI</CustomerID> <CompanyName>Alfreds Futterkiste</CompanyName> <ContactName>Maria Anders</ContactName> <ContactTitle>Sales Representative</ContactTitle> <Address>Obere Str. 57</Address> <City>Berlin</City> <Region /> <PostalCode>12209</PostalCode> <Country>Germany</Country> <Phone>030-0074321</Phone> <Fax>030-0076545</Fax> <Orders href=”Customers[ALFKI]/Orders” /> </Customer> </Customers> </DataService>
Você pode ver que a resposta inclui propriedades simples e hyperlinks com outros recursos (“Orders” no exemplo). Cada recurso também inclui um URI que representa o seu local canônico (no atributo do URI do elemento "Customer" acima).
Interação com dados da camada de apresentação
Existem várias opções para interação com fontes de dados da camada de apresentação. O primeiro aspecto que definirá o escopo das opções disponíveis para um determinado cenário é a natureza do cliente (por exemplo, navegador vs cliente rico).
Como a interface do Astoria é apenas HTTP puro, quase todos os ambientes com biblioteca de cliente em HTTP podem ser utilizados para consumir serviços de dados. A interface foi especificamente projetada para ser fácil de usar no nível HTTP; os padrões de URI são simples e legíveis por humanos e os formatos de carga usam JSON ou um subconjunto de XML que o mantém direto e simples.
Para aplicativos .NET, o conjunto de ferramentas Astoria inclui uma biblioteca de cliente executável no ambiente do .NET Framework e apresenta resultados provenientes dos serviços Astoria como objetos .NET; não apenas é o mais fácil para os desenvolvedores, para uso no âmbito da base de códigos do aplicativo cliente, mas também se integra bem com componentes que já operam sobre objetos .NET normais. A biblioteca oferece serviços ricos como gerenciamento de gráfico, rastreamento de modificações e tratamento de atualizações. (Vide Exemplo 1.)
A biblioteca de cliente do Astoria é executável tanto no .NET Framework como no Microsoft Silverlight. Isso permite a criação de aplicativos de desktop e baseados no Silverlight utilizando a mesma API, por simples referência ao respectivo conjunto Astoria no ambiente de destino.
Acessar um serviço Astoria do código .NET utilizando a biblioteca de cliente do Astoria Exemplo 1:
WebDataContext ctx = new WebDataContext(
“http://astoria.sandbox.live.com/
Northwind/Northwind.rse”);
WebDataQuery<Customer> customers = ctx.
CreateQuery<Customer>(“/Customers?$orderby=CompanyNa
me”);
foreach(Customer c in customers) {
Console.WriteLine(c.CompanyName);
}
Exemplo 2: Acessar um serviço Astoria de um aplicativo AJAX (o exemplo usa a biblioteca ASP.NET AJAX)
function ListCustomers() {
var req = new Sys.Net.WebRequest();
req.set_url(“Northwind.svc/Customers?$orderby=Co
mpanyName”);
req.get_headers()[“Accept”] = “application/json”;
req.add_completed(onCustomersCompleted);
req.invoke();
}
function onCustomersCompleted(response) {
if(response.get_statusCode() != 200)
alert(“Error retrieving customers: “ +
response.get_responseData());
else {
var res = response.get_object();
var html = “<ul>”;
for(var i = 0; i < res.length; i++) {
html += “<li>” +
res[i].CompanyName + “</
li>”;
}
html += “</ul>”;
// “Customers” is a DIV element defined in
the HTML document
$get(“Customers”).innerHTML = html;
}
}
No caso dos aplicativos web estilo AJAX, a maioria dos frameworks AJAX inclui invólucros fácil de usar para acesso de HTTP para recursos externos. Esses invólucros são até compatíveis com a materialização da resposta em objetos JavaScript se você indicar que a resposta será dada no formato JSON. (Vide Exemplo 2.)
Independentemente do tipo, os aplicativos serão executados em ambientes com latência relativamente alta entre o cliente e o serviço de dados, portanto o uso de técnicas típicas de execução assíncrona deverá ser a norma. A API cliente tem suporte incorporado para execução de requisição assíncrona. Para o caso de aplicativos AJAX, a interface XMLHTTP, com a maioria dos invólucros, oferece suporte para requisições de envio de modo assíncrono. (Vide Exemplo 3.)
Introdução à lógica do negócio
Com o Astoria, basta que o desenvolvedor aponte para um banco de dados ou esquema EDM pré-construído para que uma visão HTTP seja automaticamente gerada. Embora isso seja ótimo para as iterações iniciais de um aplicativo, essa interface totalmente aberta quase nunca será adequada à produção de aplicativos.
Em muitos bancos de dados, existe uma divisão relativamente clara entre os dois tipos de dados (quase sempre, dois tipos de tabelas): há uma parte dos dados com suficiente semântica implícita em si (isto é válido para conceitos mais simples como a "categoria de produto"). Nesses casos, a lógica do negócio (em geral magra ou inexistente) e a interface direta para os dados é o quanto basta. A outra parte dos dados só faz sentido com alguma lógica do negócio à volta dela; por exemplo, os dados apresentados precisam ficar restritos com base no contexto, ou as modificações precisam transferir validações externas ou, ainda, quando um determinado valor é alterado, outro efeito colateral precisa acontecer, e assim por diante.
Exemplo 3:Utilizar a API assíncrona no cliente Astoria para .NET
WebDataContext ctx = new WebDataContext(
“http://astoria.sandbox.
live.com/Northwind/Northwind.rse”);
WebDataQuery<Customer> q = ctx.
CreateQuery<Customer>(“/Customers[City eq 'London']”);
q.BeginExecute(
delegate(IAsyncResult ar)
{
foreach (Customer c in q.EndExecute(ar)){
// process each customer
}
},
null);
Para tratar do requisito que permite a introdução da lógica do negócio, rigidamente vinculada a determinadas peças de dados, o Astoria é compatível com dois mecanismos de personalização: operações e interceptores de serviço.
O serviço padrão do Astoria consiste inteiramente em containers de recursos localizados nos pontos de entrada do gráfico de recursos como, por exemplo, /Customers (clientes) ou / Products (produtos). Além desses, os desenvolvedores podem definir as operações de serviço que encapsulam a lógica do negócio e as consultas. Por exemplo, em um determinado aplicativo, talvez não se queira listar todos os clientes; em lugar disso, o aplicativo poderia oferecer um ponto de entrada para listar os "meus clientes" e, ainda assim, poderia haver um requisito em que os usuários pudessem recuperar, de cada vez, os clientes de uma determinada cidade. O desenvolvedor pode definir uma operação de serviço "MyCustomersByCity" (meus clientes por cidade), que obtém a identidade dos usuários do contexto (da propriedade ASP.NET's HttpContext.User, por exemplo), e depois formular uma consulta que fatore a identidade do usuário e o nome da cidade, transferida como um argumento. Por exemplo:
[WebGet]
public static IQueryable<Customer> CustomersByCity(No
rthwindEntities db, string city)
{
if (city == null || city.Length < 3) throw new
Exception(“bad city”);
var q = db.Customers.Where(“it.City = @city”,
new
ObjectParameter(“city”, city));
// add user-based filter condition to q
return q;
}
seria então invocável (callable) com um URI seguindo este padrão:
/MyCustomersByCity?city=Seattle
Um recurso interessante do Astoria é que as operações de serviço podem optar por retornar uma consulta em lugar dos resultados reais, como apresentado no exemplo anterior. Quando o objeto da consulta retorna, o restante do padrão URI ainda pode ser usado; assim, por exemplo, o cliente ainda poderia acrescentar uma opção "orderby" (pedido por) ao URI.
/MyCustomersByCity?city=Seattle&$orderby=CompanyName
A operação de serviço também pode conter código para realizar validações, atividade de registro ou qualquer outra necessidade. Tal condição oferece um bom meio termo entre o RPC rígido, que dificulta a construção de IUs flexíveis e as interfaces de dados totalmente abertas, que não permitem controlar os dados que fluem pelo sistema.
Nos cenários para os quais se deseja preservar a interface centrada em recursos, os interceptores podem ser usados. Um interceptor é um método invocado sempre que uma determinada ação acontece em um recurso no âmbito de um dado container de recursos. Por exemplo, um desenvolvedor poderia registrar um interceptor para ser invocado sempre que houver mudança (POST/PUT/DELETE) no container de recursos dos produtos ("Products"). O interceptor pode desempenhar validações, modificar valores e até escolher abortar a requisição.
Extensibilidade e fontes de dados alternativas
Até o momento, falei do Astoria no contexto do EDM e do ADO.NET Entity Framework. Utilizar o Astoria para revelar dados em um banco de dados é, sem dúvida, a melhor opção; entretanto, nem todos os dados estão em um banco de dados.
Na primeira CTP (Community Technology Preview) pública do Astoria, tínhamos nos voltado apenas para o Entity Framework. Na medida em que fazemos iterações do design do produto, estamos mudando isso para oferecer mais opções. Especificamente, para criar cenários onde se deseja expor fontes de dados, não bancos de dados, o suporte será dado utilizando qualquer fonte de dados preparados para LINQ, a serem expostos por meio da interface HTTP.
LINQ define uma interface geral denominada IQueryable: permite aos consumidores compor consultas de modo dinâmico sem precisar saber quaisquer detalhes sobre a natureza do alvo da consulta. É responsabilidade da implementação atual da IQueriable de cada fonte interpretar ou converter as consultas de modo apropriado. Isso permite ao runtime do Astoria ter uma "consulta base" para compor com operações como ordenação e paginação. (Vide Figura 2.) Com a adoção desse ponto de extensibilidade, os desenvolvedores poderão contar com um amplo conjunto de fontes de dados no cenário, expondo-as por meio da interface HTTP. Isso vai do acesso a repositórios de dados especializados ao uso de bibliotecas de acesso baseadas em LINQ para serviços online (por exemplo, existem implementações informais do LINQ para a Amazon e LINQ para o Flickr que fornecem capacidades limitadas de consulta àqueles sites da Internet).
.jpg "Bb906063.journal_13_cap03_02(pt-br,MSDN.10).jpg")
Cenários de implantação: aplicações e serviços
Hoje, um aplicativo web típico, dirigido a dados, terá o seu próprio banco de dados além de um ou mais servidores web. Para aplicativos corporativos, esses servidores fazem parte da infra-estrutura de TI e para aplicativos hospedados em ISPs, a maioria destes oferece serviços de banco de dados.
Seguindo o mesmo pensamento, espera-se que muitos aplicativos que usem o Astoria como o seu serviço de dados, construídos com base no AJAX ou Silverlight, ainda assim tenham banco de dados próprio. Nesses cenários, o serviço de dados do Astoria pode fazer parte do próprio aplicativo web e, assim, serão implantados com os demais componentes do aplicativo. Este é um dos cenários que temos com alvo para o Astoria, mas não é o único que pretendemos.
O Astoria como tecnologia para construir serviços de dados para o consumo de outros sistemas é outra forma de considerá-lo. Os provedores de dados podem configurar servidores Astoria com os quais outros aplicativos podem interagir, consumindo e atualizando dados, conforme necessário e permitido pelas diretivas de segurança. O provedor de dados pode ser o mesmo proprietário do aplicativo que consome os dados ou pode ser um serviço consumível por terceiros.
Ainda mais uma forma de considerar o Astoria é como um serviço de uso geral para armazenamento de dados. Para explorar essa idéia, configuramos um serviço online experimental que hospeda vários conjuntos de dados de exemplo, inclusive os bancos de dados Northwind e AdventureWorks, um subconjunto de artigos do Microsoft Encarta e um snapshot de dados compatíveis com o site social de marcadores Microsoft TagSpace. Transformar isso em um serviço para o mundo real exige tecnologia muito além da interface e dos padrões HTTP, e esse é um espaço fora do escopo do projeto Astoria; todavia, ainda consideramos que o serviço experimental tem valor como ferramenta de aprendizado, só para ver o que os desenvolvedores de aplicativos poderiam construir tendo-o como base.
Segurança
Expor uma interface de dados webfacing exige elaboração cuidadosa com relação ao acesso seguro, para confirmar que apenas os dados que devem ficar disponíveis estejam efetivamente acessíveis pela interface HTTP. Isso envolve uma infra-estrutura de autenticação e diretivas de autorização adequadas.
Embora muitos pontos de design do Astoria apliquem-se igualmente ao Astoria como componente de aplicativo e como serviço, a autenticação é uma das áreas à qual essa afirmação não se aplica.
.jpg "Bb906063.journal_13_cap03_03(pt-br,MSDN.10).jpg")
Se o Astoria for utilizado como serviço de dados fazendo parte de um aplicativo web personalizado, a autenticação, em geral, se aplica a todos os recursos presentes em determinada área, inclusive o acesso aos dados. Os usuários fariam a autenticação quando estivessem no website e o sistema precisa ter condições de aplicar as credenciais ao serviço de dados, assim como ao restante do aplicativo. O Astoria consulta a API do ASP.NET para saber se o usuário foi autenticado e para descobrir outros detalhes e, assim, aplicativo que use qualquer esquema de autenticação, adequadamente integrado ao ASP.NET, automaticamente trabalhará com o Astoria.
A integração com a autenticação ASP.NET significa que em casos típicos, mecanismos comuns de autenticação sobre HTTP funcionarão. Incluem-se aí "autenticação de formulários", autenticação integrada (útil no âmbito das redes corporativas) e esquemas de autenticação personalizados; é ainda mais fácil estabelecer uma implementação personalizada de autenticação "básica" de HTTP, que pode ser muito boa se usada sobre conexões SSL, dependendo da natureza do aplicativo.
Para serviços online isso se torna um desafio muito maior. Além da real problemática tecnológica de como acontece a autenticação, existem diferenças de nível mais alto que precisam ser cuidadas em primeiro lugar: se o aplicativo e o serviço de dados provêm de fontes diferentes, os dados do serviço de dados são de propriedade do usuário do aplicativo? Em caso afirmativo, o aplicativo não deveria ter acesso às credenciais do usuário para o serviço de dados? O que é preciso, nesse cenário, é ter um esquema pelo qual o usuário faz a sua autenticação no serviço de dados, independentemente do aplicativo (o qual também precisará ser autenticado). Estamos explorando este espaço como parte do esforço de projeto do Astoria e, embora tenhamos um conhecimento razoável dos cenários, ainda não projetamos uma tecnologia concreta para o seu suporte.
Depois de implantado o esquema de autenticação, é preciso ter um modelo de autorização adequado. A versão atual do Astoria (lançada na CTP de maio, 2007) tem uma implementação super simples: as diretivas de autenticação podem ser configuradas no nível do container de recursos ( /Customers, por exemplo); em cada uma delas, a configuração pode indicar se é preciso autenticação para ler os recursos do container e para escrever neles. Este procedimento não é suficientemente flexível para a maior parte dos aplicativos; assim sendo, fica claro que é preciso providenciar um esquema mais sofisticado.
Notas de encerramento: escopo e planos do projeto Astoria
A maneira pela qual os aplicativos são escritos está mudando. Uma das principais características desses aplicativos web emergentes são as novas formas pelas quais interagem com seus dados. Aqui, existe uma clara oportunidade de introduzir tecnologia básica para ajudar a comunidade de desenvolvimento a assumir este novo espaço.
Com o projeto Astoria, pretendemos dar condições para o uso de dados como um modelo de primeira classe na web e em toda a pilha de aplicativos. Queremos fornecer a infra-estrutura para a criação de serviços de dados na web e também contribuir para a criação de um ecossistema no qual os provedores e consumidores de serviços usem uma interface uniforme para os dados. Gostaríamos de ver fornecedores de controles de IU, escritores de bibliotecas de cliente e outros participantes aproveitarem o poder de reutilização das interfaces de dados para construir ferramentas melhores para a criação de aplicativos web.
Estamos iniciando esta visão em casa. Na Microsoft, estamos em estreita colaboração com muitos grupos para explorar os vários aspectos em que o Astoria pode participar. No lado dos serviços, estamos trabalhando com a organização do Windows Live, colegas da Web3S especificamente (eles são responsáveis pelas interfaces de dados das propriedades do Live), para explorar um mundo em que cada interface de dados seja uma interface Web3S/Astoria e possa ser consumida pelas várias ferramentas e controles que eles utilizam.
No lado das ferramentas, as equipes do ASP.NET, WCF e Astoria, assim como os vários colegas envolvidos com o Silverlight, estão trabalhando juntos para fornecer uma história sólida, ponta a ponta, para o desenvolvimento de aplicativos web incluindo ferramentas e bibliotecas de primeira classe para interação com dados dos aplicativos e serviços web.
O projeto Astoria anda rápido e se concentra em resolver desafios do mundo real que existem na web e com os dados. Planejamos completar o processo de projeto de forma transparente para que todos possam ver o que pretendemos. Têm sido muito bons os momentos de trabalho neste espaço; eu incentivaria qualquer um que tenha interesse no tema, a visitar o blog da equipe do Astoria, acompanhar as discussões de projeto e participar, sempre que tiver algo a dizer.
Referências
Blog da equipe Astoria:
https://blogs.msdn.com/astoriateam
Blog do Pablo:
Projeto Astoria
Sobre o autor
Pablo Castro é líder técnico da equipe do SQL Server. Contribuiu muito em várias áreas do SQL Server e do .NET Framework inclusive na integração SQL-CLR, extensibilidade (type system), no protocolo cliente-servidor do TDS e na API do ADO.NET. Atualmente, Pablo está envolvido com o desenvolvimento do ADO.NET Entity Framework e também lidera o projeto Astoria, estudando como juntar dados e tecnologias web. Antes de ingressar na Microsoft, Pablo trabalhou em várias empresas, lidando com amplo conjuntos de temas, dos sistemas de inferência distribuídos, para análise de pontuação/risco de crédito, aos aplicativos colaborativos (groupware).