Web Services e DataSets

Transcrição

1 Os Arquivos XML: Web Services e DataSets Texto Original: MSDN Magazine / Aaron Skonnard Traduzido por: Luis Gustavo Amaro ( *Atenção a possíveis erros de tradução! =D

2 Web Services e DataSets Programadores que utilizam Visual Basic 6.0 se curvaram ao altar dos conjuntos de registros ADO. Que é provavelmente a estrutura de dados mais utilizada em aplicativos baseados em Windows hoje em dia. A ADO.NET Datasets está pronta para desempenhar um papel similar no campo de gestão de aplicativos baseados em Windows. Quando você precisa extrair informação da base de dados, apresentar isso ao usuário, e aplicar atualizações, o DataSet é normalmente o melhor caminho. O DataSet foi utilizado com bastante sucesso para uma variedade de soluções tendo como alvo o Microsoft.Net Framework. No caso de Web Services, o DataSet pode causar problemas de interoperabilidade. Se você utiliza estruturas de dados dinâmica como o DataSet isso pode ser difícil para desenvolvedores que usam outras ferramentas para consumir seu Web Service. Usando DataSets tipados em combinação com definições WSDL levemente customizados, contudo, fica entorno desta questão. Desenvolvedores precisam entender as questões que envolvem todas as estruturas de dados dinâmicos (como o DataSet) antes de utiliza-los nas interfaces Web Services. Níveis de Interoperabilidade A habilidade para processar o dado indiferente de onde ele vem é o maior nível primitivo da interoperabilidade. Eu gosto de chamar isto de interoperabilidade de dados. XML 1.0 foi desenvolvido especificamente para facilitar a interoperabilidade dos dados. O dado serializado dentro do XML 1.0 é fácil para extrair e manipular em qualquer plataforma utilizando qualquer linguagem de programação para cada processador de XML existente, que engloba praticamente todas as linguagens hoje em dia. Alcançar a interoperabilidade de dados ainda requer que você escreva o código junto a uma API XML exposta pelo seu processador de XML, mas você não precisa lidar com o byte stream diretamente (veja a Figura 1). Figura 1 Interoperabilidade de dados através do XML Aplicando XML à tecnologia de aplicação distribuída (Web Services) simplifica a interoperabilidade entre sistemas heterogêneos distribuídos. Web Services podem ser construídos diretamente utilizando APIs XML. Esta aproximação lhe dá total controle sobre o processamento de mensagem, mas exige que você implemente um contrato comum na infra-estrutura do Web Service, que possa diminuir a produtividade e introduzir erros que podem levar a mais problemas de interoperabilidade. Vendedores de tecnologias distribuídas (como Microsoft) passaram ocupadas desenvolvendo ferramentas Web Services que proporcionam essa infra-estrutura comum, ajudando reduzir o código da API XML necessária do desenvolvedor Web Service. O Microsoft ASP.NET WebMethod framework é uma das ferramentas que remove quase todos os traços do baixo nível System.Xml APIs. Ferramentas Web Services realizam isto pela definição mapeamentos entre tipos de aplicativos e tipos de XML Schema, assim automatizando as transações entre os documentos XML e os objetos de instância em tempo de execução. Por exemplo, considerando o seguinte WebMethod chamado CalculateMortgage que recebe um objeto MortgageInfo como parâmetro e retorna um objeto MortgagePayments: [WebService(Namespace=" public class MortgageService : WebService [WebMethod] public MortgagePayments CalculateMortgage(MortgageInfo minfo) // calculate mortgage return new MortgagePayments(); Dentro deste mótodo, o desenvolvedor está simplesmente trabalhando com objetos, mas o [WebMethod] atributo diz a infraestrutura ASP.NET para tratar este método como operação Web Service. Então neste caso a infra-estrutura automaticamente mapeia as classes MortgageInfo e MortagePayment para definições do tipo XML Schema. Figura 2 mostra a definição das classes MortgageInfo e MortagePayment em C#, utilizadas pelo CalculateMortgage WebMethod, enquanto na Figura 3 mostra as definições do tipo XML Schema geradas pela infra-estrutura ASP.NET. Com estas definições XML Schema no lugar, está claro o que o outro lado deve esperar em termos de XML.

3 Figure 3 Definições do tipo XML Schema: <s:complextype name="mortgageinfo"> <s:element name="amount" type="s:double" /> <s:element name="years" type="s:double" /> <s:element name="interest" type="s:double" /> <s:element name="annualtax" type="s:double" /> <s:element name="annualinsurance" type="s:double" /> </s:sequence> </s:complextype> <s:complextype name="mortgagepayments"> <s:element name="monthlypi" type="s:double" /> <s:element name="monthlytax" type="s:double" /> <s:element name="monthlyinsurance" type="s:double" /> <s:element name="monthlytotal" type="s:double" /> </s:sequence> </s:complextype> Figure 2 Definições de classe: public class MortgageInfo public double amount; public double years; public double interest; public double annualtax; public double annualinsurance; public class MortgagePayments public double MonthlyPI; public double MonthlyTax; public double MonthlyInsurance; public double MonthlyTotal; Ferramentas Web Service fazem isso fácil para ignorar o XML já que o desenvolvedor Web Service lidará apenas com objetos. A Ferramenta do outro lado, porém, também quer mapear o XML para objetos. Por exemplo, um desenvolvedor que usa linguagem Java pode usar algo como a ferramenta Apache Axis para consumir este Web Service. Para usar então, ele poderia usar o utilitário WSDL2java para gerar automaticamente classes Java pelas definições do tipo XML Schema (veja Figura 4). Torna possível também ao desenvolvedor Java trabalhar com o objeto sem precisar descer para o baixo-nível do XML APIs Java.

4 Figure 4 Definições de classe Java gerada pelo Apache Axis: /** * MortgageInfo.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */ public class MortgageInfo implements java.io.serializable private double amount; private double years; private double interest; private double annualtax; private double annualinsurance; public MortgageInfo() public double getamount() return amount; public void setamount(double amount) this.amount = amount; // remainder ommited for brevity /** * MortgagePayments.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */ package mortgage_tools; public class MortgagePayments implements java.io.serializable private double monthlypi; private double monthlytax; private double monthlyinsurance; private double monthlytotal; public MortgagePayments() public double getmonthlypi() return monthlypi; public void setmonthlypi(double monthlypi) this.monthlypi = monthlypi; // remainder omitted for brevity Agora vamos discutir o próximo nível da interoperabilidade que eu gosto de chamar de Interoperabilidade de ferramenta. Interoperabilidade de ferramenta significa que eu posso escrever um código Web Service em um ferramenta e facilmente consumi-la usando outra ferramenta sem descer para o baixo-nível das APIs XML. Deve ter um objeto equivalente mapeado ou o outro lado deverá descer o nível e tratar diretamente com o XML (isto está ilustrado na Figura 5).

5 Figura 5 Interoperabilidade de ferramenta Interoperabilidade de ferramenta é difícil devido a muitas diferenças nas linguagens de programação e tipos de sistemas. O DataSet é um tipo quer apresenta alguns desafios interessantes para interoperabilidade de ferramenta. Problema do DataSet A maioria das ferramentas Web Services fazem um bom trabalho mapeando definições de classes simples como mostramos anteriormente. Eles começam a encontrar problemas, no entanto, quando derivação e substituição entram em jogo, ou quando tipos dinâmicos são utilizados, assim como collections, hash tables, or DataSets. Você deve considerar a seguinte assinatura do framework.net: [WebMethod] public DataSet GetAuthors() // return DataSet filled with authors Oque deve ser mapeado do DataSet em termos de XML Schema? O DataSet é um tipo polimórfico do qual o layout atual não foi determinado ainda em tempo de execução, depois que o DataSet foi preenchido com dados. A seguinte definição do XML Schema contém a declaração do elemento para GetAuthorsResponse. Note que GetAuthorsResponse contém um elemento opcional chamado GetAuthorsResult, que contém 2 filhos: um elemento esquema XMLSchema (s:schema), seguido por um coringa (wildcard) (s:any) indicando que qualquer elemento de qualquer namespace pode ser fornecido. <s:element name="getauthorsresponse"> <s:element minoccurs="0" maxoccurs="1" name="getauthorsresult"> <s:element ref="s:schema" /> <s:any /> </s:element> Isso indica que um esquema será fornecido em tempo de execução que será descrito o XML que conterá o mesmo. Aqui está como isso deveria parecer na resposta SOAP: <soap:envelope xmlns:soap=" xmlns:s=" <soap:body> <GetAuthorsResponse xmlns=" <GetAuthorsResult> <s:schema> *** schema goes here *** </s:schema> *** xml goes here *** </soap:envelope> Desde que a ferramenta não esteja apta para determinar o tipo atual usado no DataSet até o tempo de execução, a próxima questão é que a definição do XML Schema (apenas mostrado) deve ser mapeado no outro ambiente como a ferramenta Apache s Axis.

6 Ligação de Ferramentas No momento de estruturação, quando o desenvolvedor Java roda WSDL2Java, não terá informações suficientes na definição do esquema para fazer qualquer outra coisa a não ser mapear o elemento s:any para java.lang.object, como: public class GetAuthorsResult implements java.io.serializable private java.lang.object any; // omitted for brevity Como podemos ver, o Axis não consegue ir muito longe, porque não é como a referencia para o elemento s:schema que precede o s:any; isso gera uma exceção e falhas para produzir qualquer coisa deste tipo. Se o esquema referenciado não existir, sendo assim, a classe Java seria algo parecido com o mostrado anteriormente. Desde que nem o desenvolvedor nem a ferramenta tenha qualquer tipo adicional de informação (sobre a estrutura da informação do autor neste caso), a unica coisa que faz sentido é para a ferramenta fornecer uma DOM tree (estrutura Document Object Model) no campo que contém o XML interpretado. Por isso, para que desenvolvedores Java consumam este Web Service, eles precisarão descer e utilizar a sua API DOM equivalente diretamente. O código na Figura 6 mostra como fazer isto. Figura 6 Programa Cliente Axis (Usando APIs XML) import java.io.*; import org.example.*; import org.w3c.dom.*; import org.apache.xerces.dom.*; import org.apache.axis.message.*; public class AuthorsClient static void main(string[] args) throws Exception DataSetServiceSoapStub stub = new DataSetServiceSoapStub(new java.net.url(" null); GetAuthorsAsTypedDataSetResult result = Object any = result.getany(); // it's really a DOM tree Element docelement = (Element)any; stub.getauthors(); NodeList authors = docelement.getelementsbytagnamens(" "authors"); for (int i=0; i<authors.getlength(); i++) Element authorselem = (Element)authors.item(i); ElementImpl fnameelem = (ElementImpl)authorsElem.getElementsByTagNameNS( " System.out.println(fnameElem.getTextContent()); Nós vamos nos deparar com este problema com qualquer ferramenta, isso não é um caso especial para os DataSets no.net Framework. Você sempre precisara negociar com a DOM API diretamente usando a ferramenta Microsoft SOAP para desenvolvedores COM. De acordo com as definições que eu disponibilizei anteriormente, ainda há interoperabilidade de dados nesta situação (isto é apenas XML), mas um nível da interoperabilidade de ferramenta é perdida desde que o desenvolvedor é obrigado a negociar com o XML puro. Se eu sei que estou retornando uma coleção de gravações do autor com um formato bem definido, existem algumas maneiras que eu poderia fazer isto facilmente para usuários de outras ferramentas, para processar meus dados sem acessar as APIs XML diretamente.

7 Evitando DataSets Provavelmente o jeito mais fácil de fazer isso, é não utilizar DataSets na sua interface Web Service. Por exemplo, neste caso você poderia definir uma classe que modela as informações do autor, e declarar o método GetAuthors como a seguir: public class Author public string id; public string au_fname; public string au_lname; [WebMethod] public Author[] GetAuthors() DataSet authorsds = GetAuthorsFromDB(); // walk through DataSet and generate // Author array to return Aqui estou mapeando manualmente um DataSet para um tipo estático do Author (já que estou provavelmente usando o DataSet aqui para receber os dados do banco de dados, provavelmente faz mais sentido usar IDataReader diretamente, podendo prover uma solução mais eficiente). Neste caso eu poderia fazer naturalmente um mapeamento entre a classe Author e a definição do XML Schema equivalente, que mapearia também de volta muito bem para uma classe Java equivalente (como o exemplo CalculateMortgage mostrado anteriormente). Com algo assim no lugar, o desenvolvedor Axis poderia estar apto a escrever um código sem precisar acessar as API s XML diretamente (veja a Figura 7). Outra maneira de efetuar isto poderia ser gerar um DataSet tipado de uma definição XML Schema e usá-la no lugar de um DataSet genérico. Figura 7 Cliente Axis (Sem APIs XML) import java.io.*; import org.example.*; public class AuthorsClient static void main(string[] args) throws Exception DataSetServiceSoapStub stub = new DataSetServiceSoapStub(new java.net.url( " null); Author[] authors = stub.getauthors(); for (int i=0; i<authors.length; i++) System.out.println(authors[i].getAu_Fname()); DataSets Tipados DataSets Tipados são classes derivadas de DataSets e expõe os membros fortemente tipados que descrevem uma visão específica dos dados. Diferente dos DataSets genéricos, os DataSets tipados são obrigado a uma estrutura específica, uma definição de XML Schema, em tempo de projeto. Você pode gerar automaticamente DataSets tipados a partir de definições XML Schema usando o xsd.exe ou os designers embutidos no Visual Studio.NET. Figura 8 contém uma definição XML Schema que descreve as gravações do autor que eu pretendo retornar para minha Web Service. Após executar este esquema através do xsd.exe usando o /dataset switch (ou o designer do Visual Studio.NET), Eu terei uma nova classe chamada AuthorSet derivada do DataSet, como mostrado aqui: [Serializable()] public class AuthorSet : DataSet private authorsdatatable tableauthors; // strongly typed accessors

8 Figura 8 Definição do XML Schema do DataSet Tipado (AuthorSet.xsd) <xs:schema id="authorset" targetnamespace=" xmlns=" xmlns:xs=" elementformdefault="qualified" > <xs:element name="authorset" > <xs:complextype> <xs:choice maxoccurs="unbounded"> <xs:element name="authors"> <xs:complextype> <xs:sequence> <xs:element name="au_id" type="xs:string" /> <xs:element name="au_lname" type="xs:string" /> <xs:element name="au_fname" type="xs:string" /> </xs:sequence> </xs:complextype> </xs:element> </xs:choice> </xs:complextype> </xs:element> </xs:schema> A infra-estrutura sabe que a definição do esquema deve ser para este DataSet tipado, então ele não precisa mais prover um esquema em tempo de execução (embora ele ainda faz). Agora nós podemos criar um novo WebMethod que retorna um objeto AuthorSet: [WebMethod] public AuthorSet GetAuthorsAsTypedDataSet() AuthorSet aus = new AuthorSet(); sqldataadapter1.fill(aus); return aus; Agora a infra-estrutura tem informação suficiente para informar os clientes em tempo de projeto sobre a estrutura das gravações do autor no conjunto retornado. Quando a estrutura ASP.NET gerar o WSDL e as definições do XML Schema, contudo, importa as definições XML Schema do DataSet tipado e utiliza coringa restrito, como mostrado na Figura 9.

9 Figura 9 Definição XML Schema do método GetAuthorsAsTypedDataSet <definitions xmlns:s=" targetnamespace=" xmlns=" > <import namespace=" location=" /> <types> <s:schema elementformdefault="qualified" targetnamespace=" <s:import namespace=" /> <s:element name="getauthorsastypeddatasetresponse"> <s:element minoccurs="0" maxoccurs="1" name="getauthorsastypeddatasetresult"> <s:any namespace=" /> </s:sequence> </s:complextype> </s:element> </s:sequence> </s:complextype> </s:element> </s:schema> </definitions> Uma vez que já não há referência para o elemento s:schema, WSDL2Java está apto a gerar as classes Java corretamente. E uma vez que importado as definições lhe dá acesso as definições do XML Schema para AuthorSet, isto pode gerar as classes Java equivalentes que representam as informações do autor. Axis, contudo, ainda mapeia o coringa (s:any) para java.lang.object, quais vão conter uma DOM tree (estrutura Document Object Model) em tempo de execução. Isso me deixa ainda mais do que antes, mas ainda deixa o cliente trabalhando com a API DOM diretamente. Customizando o Esquema Uma vez que você sabe que o slot coringa sempre conterá um AuthorSet, você pode ser tentado apenas a modificar a definição do esquema para referenciar o elemento AuthorSet ao invés do coringa. O coringa, contudo, é atualmente um espaço reservado para o esquema do DataSet genérico (que não faz muito sentido uma vez que o coringa está amarrado ao namespace). Em outras palavras, quando você executa o WebMethod, o elemento GetAuthorsAsTypeDataSetResult conterá um elemento esquema seguido por um elemento diffgram, e o elemento diffgram conterá o elemento AuthorSet. Mas uma vez que você conhece a estrutura antes da hora, você não precisa fornecer um esquema em tempo de execução ou um elemento diffgram; você pode simplesmente retornar um elemento AuthorSet. O modo de fazer isto é definir um novo WebMethod que não retorna um DataSet, mas sim um XmlNode. Então se você retornar um XmlDataDocument que envolve um objeto DataSet tipado, apenas o elemento AuthorSet é retornado ao cliente, sem o esquema de tempo de execução ou elementos diffgram: [WebMethod] public XmlNode GetAuthorsAsXml() AuthorSet aus = new AuthorSet(); sqldataadapter1.fill(aus); return new XmlDataDocument(aus); O XmlDataDocument é ineficiente uma vez que ele praticamente dobra o tamanho do DataSet original. Desde que seja por pouco tempo, isso pode ser aceitável.

10 Especificando que o método retorna um XmlNode também irá resultar em um coringa no esquema gerado, mas agora você pode reescrever o coringa com uma referência ao elemento AuthorSet, como mostrado a seguir: <s:element name="getauthorsasxmlresponse"> <s:element minoccurs="0" maxoccurs="1" name="getauthorsasxmlresult"> <s:element ref="x:authorset" /> </s:sequence> </s:complextype> Você deverá ter certeza que os clientes não recuperarão o arquivo WSDL gerado automaticamente uma vez que você iniciar este caminho. Em vez de você vai querer especificar a localização de um arquivo WSDL customizado usando o WebServiceBindingAttribute (veja a prorpriedade Location) ou fornecendo um arquivo WSDL estático no seu servidor e desabilitando a geração automática do WSDL. Você pode desabilitar a geração automática do WSDL adicionando a seguinte sessão no seu arquivo web.config: <webservices> <protocols> <remove name="documentation" /> </protocols> </webservices> Agora o WebService pode ainda trabalhar com DataSets e outros clientes podem processar os resultados como um array de objetos. Figura 10 mostra como um cliente Axis se parece neste caso. Figura 10 Cliente Axis de um DataSet Tipado import org.example.*; public class AuthorsClient static void main(string[] args) throws Exception DataSetServiceSoapStub stub = new DataSetServiceSoapStub(new java.net.url ( " null); GetAuthorsAsTypedDataSetResult res = stub.getauthorsastypeddataset(); AuthorSet aset = res.getauthorset(); Author[] authors = aset.getauthors(); for (int i=0; i<authors.length; i++) System.out.println(authors[i].getAu_Fname()); Se isso parecer uma grande confusão usar DataSets, você pode sempre evitar eles nas suas interfaces Web Services ou simplesmente exigir de seus cliente que lidem diretamente com o XML. Isso tudo se resume ao o que você quer que as outras ferramentas vejam. A Solução Final Este problema poderia eventualmente sumir se a indústria definisse um padrão de definição do XML Schema para representar os conjuntos de resultados do banco de dados e todas as ferramentas suportem isso apropriadamente. Então as ferramentas poderiam mapear seus tipos de conjuntos de dados nativos para o esquema padronizado. A mesma coisa para outros tipos dinâmicos como collections, hash tables, lists, queues, e muito mais. Padronizando as definições do XML Schema para tais tipos teria o efeito de promover a interoperabilidade de ferramenta através de uma vasta gama de extrema eficiência e geralmente estruturas de dados usadas. Se isso fosse uma realidade, você poderia retornar uma DataSet genérico (como o primeiro exemplo GetAuthors) e a ferramenta Axis poderia mapeá-la para um JDBC WebRowSet (ou algo equivalente). Então o desenvolvedor Java poderia ligar o WebRowSet com um componente UI, permite o usuário modificar o dado, e passar um conjunto atualizado de volta ao servidor tudo com muito pouco código. O conjunto atualizado pode então ser deserializado de volta dentro do DataSet no servidor, a fim de aplicar as alterações aos dados. Esta solução faz o maior sentido, se você pensa porque você precisa utilizar um DataSet em um Web Service. DataSets são tipicalmente usado quando você precisa apresentar um dado ao usuario de uma forma genérica (normalmente em uma grade), permitindo o usuário fazer modificações, e devolver as atualizações ao servidor. As técnicas apresentadas aqui não suportam este

11 padrão (desde que você não receba vinculação de dado ou suporte diffgram com DOM tree (estrutura Document Object Model) ou arrays), então isto é como martelar um taco quadrado em um buraco redondo. Claro, padronizar qualquer coisa nesta indústria é muito mais fácil dizer do que fazer. Não prenda a respiração esperando por cada padrões que venham codificados e suportados inteiramente nas ferramentas de hoje em dia. Uma Solução.Net Framework Você provavelmente já viu demonstrações em feiras de negócio no passado aonde o apresentador retornava um DataSet para um cliente.net Framework e de alguma maneira isto magicamente tornava-se um DataSet do outro lado. Isto funciona porque a infraestrutura Web Service no.net Framework procura por uma flag especial na definição do XML Schema fornecido em tempo de execução chamado IsDataSet. Por exemplo, no caso do exemplo GetAuthorsAsTypedDataSet, declaração do elemento AuthorSet parecerá como isto no esquema fornecido em tempo de execução: <xs:element name="authorset" msdata:isdataset="true"> A flag IsDataSet é o toque para o cliente, dizendo para deserializar o XML dentro de um DataSet. Obviamente, isto funciona apenas para cliente.net Framework ou outras ferramentas que tem fornecido este caso especial codificado (não tem nenhum que eu conheça atualmente). O código na Figura 11 mostra como um cliente Visual Basic.NET poderia invocar ambos GetAuthors e GetAuthorsAsTypedDataSet e facilmente mapear o DataSet retornado para um DataGrid (em um formulário Windows). Figura 11 Mapeando um DataSet para um DataGrid Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Dim svc As DataSetService = New DataSetService() Dim ds As DataSet = svc.getauthors() DataGrid1.DataSource = ds.tables.item(0) End Sub Private Sub Button2_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button2.Click Dim svc As DataSetService = New DataSetService() Dim auset As AuthorSet = svc.getauthorsastypeddataset() DataGrid1.DataSource = auset.authors End Sub Isto deveria ser apenas como uma fácil através de todas as ferramentas e uma variedade APIs de banco de dados se tivéssemos uma esquema padronizado para os conjuntos de resultados de banco de dados que todos suportassem. Ironicamente, uma vez que você tem algo assim no lugar, atualmente isto é mais tedioso trabalhar com um array de objetos Author quando o sua meta é apresentar o dado ao usuário para uma manipulação genérica. Resumindo XML e Web Services fornecem interoperabilidade básica de dados atualmente. Se você estiver disposto a trabalhar com APIs XML, não há um Web Service no mundo que você não consiga consumir. Se, contudo, se você prefere esconder as APIs XML embaixo do tapete e nunca lidar com ele de novo, tenha cuidado com tipo dinâmicos como o DataSet. Utilizazndo o DataSet genérico na interface DataSet forçará os desenvolvedores a usar outras ferramentas para lidar com o XML diretamente. Utilizando DataSets tipados em combinação com definições WSDL levemente customizadas contorna este problema expondo os resultados como um simples array de objetos. A solução definitiva, contudo, seria padronizar uma definição de XML Schema para representar conjuntos de resultados de banco de dados que poderia ser comportado em todos as ferramentas. Envie suas dúvidas e comentários (em inglês) para Aaron > [email protected].