Utilizao de Web Services na plataforma .NET para a criao de um aplicativo visualizador de notcias para dispositivos mveis
Palmas 2003 ii
MICHAEL SCHUENCK DOS SANTOS
Utilizao de Web Services na plataforma .NET para a criao de um aplicativo visualizador de notcias para dispositivos mveis
Monografia apresentada como requisito parcial da disciplina de Trabalho de Concluso de Curso (TCC) do curso de Sistemas de Informao, orientado pelo Prof. Jackson Gomes de Souza
Palmas 2003 iii
MICHAEL SCHUENCK DOS SANTOS
Utilizao de Web Services na plataforma .NET para a criao de um aplicativo visualizador de notcias para dispositivos mveis
Monografia apresentada como requisito parcial da disciplina de Trabalho de Concluso de Curso (TCC) do curso de Sistemas de Informao, orientado pelo Prof. Jackson Gomes de Souza
Aprovado em dezembro de 2003
BANCA EXAMINADORA
_____________________________________________ Prof. Jackson Gomes de Souza Centro Universitrio Luterano de Palmas
_____________________________________________ Prof. Eduardo Kessler Piveta Centro Universitrio Luterano de Palmas
_____________________________________________ Prof. Madianita Bogo Centro Universitrio Luterano de Palmas
Palmas 2003
iv
O computador ter o tamanho que voc quiser. Poder ser do tamanho da sua carteira ou da sua parede.
(Bill Gates, Abril de 1992)
v AGRADECIMENTOS
Agradeo, primeiramente a Deus, tanto por sua bondade em conceder a mim e a todas demais pessoas do meu convvio, uma grande ddiva; quanto por seu empenho em me motivar a ser o que fui, que sou e que pretendo ser por meio do meu labor. Agradeo minha famlia, em particular minha me, que por muitas vezes estranhou tamanha dedicao a uma das jornadas mais desgastantes e ao mesmo tempo recompensadoras, mas que me fez forte (ou teimoso) em seguir naquilo em que eu acreditava. Agradeo ao meu orientador, o jovem professor Jackson, que sabiamente me orientou como um veterano neste trabalho, evidenciando a ilimitao da mente humana ao demonstrar conhecimento sobre os mais diversos temas. Agradeo particularmente aos professores Deise, Fabiano e Parcilene. Deise, que direcionou meus primeiros passos cientficos, no PROICT e no Estgio, e que sempre faceira estava a responder minhas dvidas. Ao Fabiano por me fazer cair a ficha de que eu podia aproveitar melhor meus tempos de universitrio, me apresentando formalmente a cincia. Parcilene por mostrar que a carpa pode vislumbrar um mundo adicional e inovador fora do tanque (no apenas nas aulas de Informtica e Sociedade). Agradeo aos professores que me viram entrar em suas aulas: Ademildo, Andrs, Augusto, Cristina, Eduardo Leal, Eduardo Piveta, Madianita, Madson, Mrio Srgio, Santo Reny, Thereza. Agradeo aos tambm alunos, ex-alunos ou colaboradores de Sistemas de Informao, que me deram a honra de sua presena: Alan, Alessandro Brando, lvaro, Anderson, Antonio da Luz, Danilo, Dilton, Edeilson, Elaine, Fernando Luiz, Francisco de Assis dos Santos Jr., Heres, Jansle, Knia, Lucas, Marcus, Marcelo Leal, Nalva, Paulo, Pollyane, Raphael Lobo, Renatto Mota, Ricardo Marx. Agradeo tambm ao leitor que neste momento me prestigia ao ler este trabalho. Agradeo! Exceto em relao ao primeiro pargrafo, a ordem dos demais no indica preferncia, afinal, isto nem mesmo eu sei responder. Os nomes contidos nos pargrafos esto em ordem alfabtica. vi SUMRIO
SUMRIO...................................................................................................................... VI 1 INTRODUO .......................................................................................................... 13 2 REVISO DE LITERATURA.................................................................................. 15 2.1 A TECNOLOGIA DE WEB SERVICES........................................................................... 15 2.2 XML ...................................................................................................................... 17 2.3 NAMESPACES........................................................................................................... 19 2.4 XML SCHEMA........................................................................................................ 21 2.4.1 Elementos........................................................................................................ 22 2.4.2 Atributos ......................................................................................................... 23 2.4.3 Tipos de dados................................................................................................ 24 2.5 SOAP..................................................................................................................... 24 2.5.1 Envelope SOAP............................................................................................... 26 2.5.1.1 SOAP Fault.............................................................................................. 28 2.5.2 Regras de codificao .................................................................................... 29 2.5.3 Serializao XML ........................................................................................... 30 2.5.4 SOAP RPC...................................................................................................... 31 2.5.5 Ligao entre HTTP e SOAP.......................................................................... 32 2.6 HTTP-GET E HTTP-POST ................................................................................... 34 2.7 WSDL.................................................................................................................... 36 2.7.1 Elemento types................................................................................................ 37 2.7.2 Elementos message......................................................................................... 38 2.7.3 Elementos portType ........................................................................................ 39 2.7.4 Elementos binding .......................................................................................... 39 2.7.5 Elemento service............................................................................................. 40 2.8 UDDI ..................................................................................................................... 41 2.9 CRIAO DE WEB SERVICES DA PLATAFORMA .NET............................................... 42 2.9.1 Arquivos ASMX............................................................................................... 43 2.9.2 Autenticao de Web Services........................................................................ 47 2.10 CONSUMO DE WEB SERVICES NA PLATAFORMA .NET ........................................... 49 2.10.1 Gerao da classe proxy .............................................................................. 49 2.10.2 Compilao da classe proxy......................................................................... 50 2.11 DISPOSITIVOS MVEIS BASEADOS NA PLATAFORMA POCKET PC.......................... 51 3 MATERIAL E MTODOS....................................................................................... 53 3.1 LOCAL E PERODO ............................................................................................ 53 3.2 MATERIAL........................................................................................................ 53 3.3 METODOLOGIA....................................................................................................... 54 4 RESULTADOS E DISCUSSO................................................................................ 55 4.1 BANCO DE DADOS DE NOTCIAS .............................................................................. 56 4.2 CLASSE PARA ACESSO AO BANCO DE DADOS........................................................... 57 4.3 CLASSES PARA REPRESENTAO DAS NOTICIAS...................................................... 58 4.4 CLASSE PARA REPRESENTAO DO WEB SERVICE................................................... 59 4.5 A APLICAO PARA DISPOSITIVOS MVEIS............................................................. 62 vii 5 CONSIDERAES FINAIS..................................................................................... 67 REFERNCIAS BIBLIOGRFICAS ........................................................................ 69
viii LISTA DE FIGURAS
Figura 1: Aplicao na Internet acessando diferentes Web Services............................. 16 Figura 2: Documento XML............................................................................................. 18 Figura 3: Documento XML utilizando Namespace ........................................................ 20 Figura 4: Documento XML utilizando Namespace com prefixos................................... 21 Figura 5: Elementos simples em XML Schema............................................................... 22 Figura 6: Elemento complexo em XML Schema............................................................. 23 Figura 7: Atributo em XML Schema............................................................................... 24 Figura 9: Etapas na comunicao entre servidores....................................................... 25 Figura 10: Representao de um envelope SOAP (MSDN, 2003B) ............................... 26 Figura 11: Envelope SOAP (BALLINGER, 2003).......................................................... 27 Figura 12: Envelope SOAP reportando um erro (SOAP, 2003) .................................... 29 Figura 13: Classe a ser codificada (BALLINGER, 2003) .............................................. 30 Figura 14: Resultado da codificao SOAP (BALLINGER, 2003) ................................ 30 Figura 15: Chamada remota a um mtodo com SOAP (BALLINGER, 2003)................ 32 Figura 16: Requisio SOAP utilizando HTTP.............................................................. 33 Figura 17: Resposta SOAP utilizando HTTP ................................................................. 34 Figura 18: Requisio HTTP-GET................................................................................. 34 Figura 19: Resposta HTTP-GET .................................................................................... 35 Figura 20: Requisio HTTP-POST............................................................................... 35 Figura 18: Elementos message em um documento WSDL ............................................ 36 Figura 19: Elemento types em um documento WSDL.................................................... 37 Figura 20: Elementos message em um documento WSDL ............................................ 38 Figura 21: Elementos portType em um documento WSDL ............................................ 39 Figura 22: Elementos binding em um documento WSDL............................................... 40 Figura 23: Elementos service em um documento WSDL ............................................... 41 Figura 24: Exemplo de arquivo ASMX........................................................................... 44 Figura 25: Visualizao de um arquivo ASMX em um browser..................................... 45 Figura 26: Interface para insero dos parmetros do mtodo somar ......................... 46 Figura 27: Resultado da execuo do mtodo somar .................................................... 47 Figura 28: Classe para representao de cabealho de SOAP ..................................... 48 Figura 29: Servio autenticado atravs de cabealho de SOAP.................................... 48 ix Figura 30: Classe proxy para o Web Service definido na figura 24Erro! Indicador no definido. Figura 31: Aplicao C# invocando o mtodo somar do Web Service da figura 24 ..... 50 Figura 32: Tela principal do emulador de Pocket PC ................................................... 52 Figura 33: Modelo da arquitetura desenvolvida............................................................ 55 Figura 34: Esquema do banco de dados para armazenamento das notcias ................. 56 Figura 35: Classe Banco, usada para acesso ao banco de dados.................................. 57 Figura 36: Classe Noticia, usada para representar notcias.......................................... 59 Figura 37: WebMethod NoticiasDaInstituicao .............................................................. 60 Figura 38: Resultado da execuo do mtodo NoticiasDaInstituicao ........................... 61 Figura 39: Tela do emulador exibindo os ttulos das notcias dos cursos ..................... 63 Figura 40: Mtodo preencherLV, da classe FormConsumer......................................... 64 Figura 41: Tela do emulador exibindo os detalhes de uma notcia ............................... 65 Figura 42: Mtodo setNoticia, da classe FormDetalhes................................................ 66
x LISTA DE ABREVIATURAS
ASMX = Active Server Method Extension DTD = Document Type Definition HTTP-GET = HyperText Transfer Protocol - Get HTTP-POST = HyperText Transfer Protocol - Post IIS = Internet Information Services IRI = Internationalized Resource Identifiers PDA = Personal Digital Assistant SOAP = Simple Object Access Protocol UDDI =Universal Description, Discovery and Integration URI = Uniform Resource Identifier URL = Uniform Resource Locators W3C = World Wide Web Consortium WAP = Wireless Application Protocol WSA =Web Services Achitecture WSDL = Web Services Description Language XML = eXtensible Markup Language XML-RPC = XML Remote Procedure Call xi
RESUMO
A tecnologia de Web Services vm se destacando como uma boa opo para comunicaes remotas. Isto se deve ao fato desta tecnologia utilizar XML, o que permite que aplicaes de diferentes plataformas se comuniquem. Da mesma forma, a utilizao de dispositivos computacionais mveis tem se tornado cada vez mais popular. Assim, este trabalho apresenta um modelo desenvolvido para a utilizao destas duas tecnologias, utilizando-se a plataforma .NET, concretizada em uma aplicao para visualizao de notcias em dispositivos mveis.
Palavras-chaves: XML, Web Services, Dispositivos Mveis
xii ABSTRACT
The Web Services technology has being emerged as a good option to remote comunications. This is because this techonology allows the use of remote methods, obtaining well portability, that is possible by the use of XML. In the same way, the use of mobile devices, have becoming very used. Therefore, this work presents a model developed to use these two technologies, using the .NET framework, materialized in a application to visualization of news on mobile devices.
Keywords: XML, Web Services, Mobile Devices
13
1 INTRODUO
A tecnologia de Web Services oferece recursos para a utilizao, atravs da Internet, de classes e mtodos remotos. Seu objetivo permitir que aplicaes de diferentes plataformas se comuniquem. Para isto, utilizada a XML, que o formato de dados utilizado para o transporte das informaes trocadas, e que caracterizado pela interoperabilidade. Assim, esforos tm sido dispendidos para que um Web Service desenvolvido na plataforma .NET possa ser acessado por uma aplicao desenvolvida na plataforma Java, e vice-versa, por exemplo. O cdigo dos Web Services da plataforma .NET, que foi utilizada no contexto deste trabalho, semelhante ao cdigo de classes normais, em linguagem de programao, alterando-se apenas algumas diretivas. Para que as comunicaes sejam possveis, necessrio um conhecimento por parte da aplicao final, de quais so as funcionalidades oferecidas pelo Web Service, o que feito atravs de documentos WSDL. Para a comunicao efetiva, podem ser utilizados alguns protocolos: HTTP-POST, HTTP-GET e SOAP, que permite a representao de dados complexos. Tanto estes protocolos quanto os documentos WSDL so baseados em XML, sendo este aspecto que possibilita a interoperabilidade, pois atravs destes artefatos que as mensagens so transportadas. Outra tecnologia utilizada neste trabalho so os dispositivos computacionais mveis, denominados PDAs, que representam uma forma de comunicao e tratamento de dados, caracterizados pela mobilidade, e que tm se tornado bastante populares. Assim, o objetivo principal deste trabalho apresentar um modelo para utilizao conjunta destas duas tecnologias emergentes, exemplificada atravs de um aplicativo para rodar em PDAs que utilizem a plataforma operacional Pocket PC. A funo do aplicativo 14 desenvolvido apresentar notcias localizadas em um banco de dados remoto, que so acessadas por meio dos mtodos do Web Service desenvolvido. Este trabalho est organizado da seguinte forma: o captulo 2 apresenta os aspectos tericos agregados pela tecnologia de Web Services e pelos dispositivos mveis; o captulo 3 apresenta os materiais e mtodos utilizados para a realizao do trabalho; em seguida, o captulo 4 apresenta os detalhes do banco de dados de notcias, bem como da implementao do Web Service e da aplicao para dispositivos mveis; o captulo 5 apresenta as consideraes finais sobre todo o trabalho; e por fim, so apresentadas as referncias bibliogrficas utilizadas para a execuo deste trabalho. 15
2 REVISO DE LITERATURA
Como parte integrante deste trabalho, foi realizada uma reviso bibliogrfica sobre a tecnologia de Web Services, alm dos recursos disponibilizados pela plataforma .NET para a sua criao e utilizao. Foram analisadas, ainda, as particularidades de se construir aplicaes para dispositivos mveis, utilizando-se a plataforma .NET. Estes itens sero vistos com mais detalhes atravs das prximas sees.
2.1 A tecnologia de Web Services
A plataforma .NET oferece uma vasta lista de funcionalidades para a realizao de tarefas diversas, porm, centradas na orientao a objetos e em uma grande integrao com a Internet. Dentre os recursos oferecidos, incluem-se os Web Services (Servios da Web), que tambm so oferecidos por outras plataformas, como Java, por exemplo. A tecnologia de Web Services permite que aplicaes tambm se comuniquem. Ou seja, o contedo pode ser transmitido atravs da Internet, por um Web Service, e recebido por uma aplicao remota, pela qual os dados podem ser utilizados de variadas maneiras: processados e exibidos em uma pgina da Internet, em uma aplicao desktop, ou em um dispositivo mvel (utilizado na implementao deste trabalho para acessar dados de um Web Service). Neste sentido, pode-se fazer uma analogia orientao a objetos tradicional, sendo que os Web Services so utilizados da mesma maneira que classes, no cliente, com a diferena que, em se tratando de Web Services, os mtodos podem ser acessados remotamente (AMUNDSEN, 2002). Isto permite que uma aplicao utilize dados e processamento de diferentes lugares na Internet simultaneamente. Esta situao 16 exemplificada pela figura 1, em que uma aplicao que utiliza a Internet, localizada em Porto Alegre, possui mdulos cujos dados, ou mesmo somente a lgica (que o caso da utilizao do Web Service localizado em Palmas), so acessados atravs dos mtodos e propriedades disponibilizados por Web Services localizados em servidores de Braslia, Rio de Janeiro e Palmas.
Figura 1: Aplicao na Internet acessando diferentes Web Services
Outra caracterstica desta tecnologia o fato de os dados trocados serem baseados no protocolo SOAP, que baseado em XML. Sendo SOAP um protocolo aberto, possvel que aplicaes de diferentes plataformas se comuniquem (AMUNDSEN, 2002). Neste sentido, o W3C tem trabalhado, no desenvolvimento de uma definio padro, a WSA, que objetiva fazer com que as implementaes para a tecnologia de Web Services de diferentes empresas sigam princpios bsicos para que a interoperabilidade seja mantida (WSA, 2003). Uma definio para o termo Servios da Web, no contexto das caractersticas j apresentadas e de outras que sero ainda apresentadas, a seguinte:
Um Web Service um sistema de software projetado para suportar interao mquina-a-mquina sobre uma rede. Ele tem uma interface descrita em um formato processvel por mquina (especificamente WSDL). Outros sistemas interagem com o Web Service em uma maneira aconselhada por esta descrio usando mensagens SOAP, tipicamente transportadas usando HTTP com uma 17 serializao XML em conjuno com outros padres relacionados Web. (WSA, 2003)
Em outras palavras, esta definio informa que Web Services so artefatos de software acessados por aplicaes remotas. Para isto, as mensagens trocadas so formatadas no protocolo SOAP, o que garante a interoperabilidade entre diferentes plataformas, em um processo denominado serializao XML. Porm, antes que as mensagens SOAP sejam trocadas, suas caractersticas so explicitadas atravs de documentos WSDL, que descrevem quais dados estaro sendo trocados, e como estes dados estaro organizados nas mensagens SOAP. Como as mensagens SOAP e WSDL so, na verdade, documentos XML, elas so estruturadas por esquemas descritos atravs de XML Schemas, que, por sua vez, baseiam- se na utilizao de Namespaces. Adicionalmente, os Web Services podem ser tornados pblicos atravs de um mecanismo denominado por UDDI. Este um formato para armazenamento de referncias para Web Services em repositrios acessveis pela Internet. Assim, se um desenvolvedor precisa de um Web Service para realizao de uma determinada tarefa, pode encontrar o Web Service que mais se adeqe sua necessidade. Normalmente, o protocolo de rede utilizado no transporte destas mensagens HTTP. Aps ter sido apresentado o modelo da interao entre as tecnologias utilizadas neste trabalho, as sees seguintes apresentaro com mais detalhes cada uma destas tecnologias.
2.2 XML
A XML (XML, 2003) um padro do W3C para representao de dados. Possui um formato simples e muito til para o intercmbio de dados, o que conseguido atravs da caracterstica de marcao da linguagem. Uma caracterstica marcante na XML a possibilidade de definio de novas linguagens de marcao. Isto possvel pelo fato de as tags de marcao poderem ser 18 definidas pelo usurio. Por isto, pode-se dizer que dados semi-estruturados so bem representados pela XML. A XML tem duas formas primrias de composio de informaes: os elementos e os atributos. Os elementos so estruturas que permitem a atribuio de dados simples, tais como seqncias de nmeros e letras (elementos simples) e de outros elementos (elementos complexos). Seus nomes so definidos entre os sinais < (menor) e > (maior), e a este conjunto se d o nome de tag ou n. Cada tag que aberta deve ser fechada, o que feito com a repetio da tag de abertura, porm, utilizando-se / (barra) antes do nome do elemento. Existe ainda, um tipo de tags que no contm mais dados que apenas seu nome e atributos. Neste caso, antes do sinal de maior, deve ser colocada a barra. O contedo do elemento colocado entre as tags de abertura e a de fechamento. Os atributos so ainda mais simples: constituem-se de estruturas para atribuio de valores alfanumricos e so colocados junto s tags de abertura dos elementos. A figura 2 exibe um documento XML.
1 <documentos> 2 <artigo id=a1> 3 <autor> Manoel de Sousa </autor> 4 <titulo> Dados Semi-Estruturados </titulo> 5 <instituicao> CEULP/ULBRA </instituicao> 6 </artigo> 7 <artigo id=a2> 8 <autor> Joana dos Santos </autor> 9 <titulo> Armazenamento de XML em SGBDOO's </titulo> 10 <instituicao> CEULP/ULBRA </instituicao> 11 <area> Bancos de Dados </area> 12 </artigo> 13 </documentos> Figura 2: Documento XML
O documento apresentado formado de elementos compostos, tais como documentos e artigo, que so compostos por outros elementos. Exemplos de elementos simples so autor e titulo, que contm dados propriamente ditos. Alm destas representaes de dados, este documento contm atributos, com o nome id, nos elementos artigo. Os documentos XML podem ser validados contra estruturas determinadas, de forma que se possa ter vrios documentos que sigam a mesma estruturao (ANDERSON, 2001). Estas estruturas podem ser definidas atravs de DTDs e XML Schemas. Em se 19 tratando de Web Services, vrios dos componentes desta tecnologia so, na verdade, documentos XML. o caso das mensagens SOAP e documentos WSDL, que possuem sua estrutura representada atravs de XML Schemas (que so tambm, documentos XML), que sero apresentados na prxima seo, juntamente com a tecnologia de namespaces.
2.3 Namespaces
Normalmente, um documento XML bem formado possui uma estrutura equivalente que o defina, ainda que esta no esteja explicitamente definida. Ou seja, quando se cria um documento XML sobre um determinado assunto, automaticamente, ele possui uma estruturao que pode ou no estar representada de alguma maneira (DTD ou XML Schema, principalmente). Isto sugere que cada documento deve ter seus dados validados por apenas uma estrutura. Porm, um nico documento XML pode tratar de vrios domnios simultaneamente, fazendo com que a estrutura que representa o documento aborde todos os domnios suportados. Por outro lado, muitas vezes, representaes dos domnios utilizados podem ter sido definidos anteriormente por outras pessoas. Assim, a reutilizao destas estruturas seria uma boa sada para a construo de documentos XML com mais rapidez (sem a necessidade de se pensar na organizao do documento novamente), permitindo a existncia de estruturas padro para a representao de determinados domnios em XML, alm de, adicionalmente, permitir que sistemas computacionais interpretem, de forma adequada, os diferentes mdulos do documento (NAMES, 2003). Desta forma, surge uma abordagem que permite que cada documento XML agregue dados que seguem estruturaes diferentes. Por outro lado, um documento com trechos que seguem estruturas diferentes pode acabar possuindo elementos e atributos com mesmo nome, mas significados diferentes (BALLINGER, 2003). Neste sentido, para permitir que documentos sejam representados por mais de uma estrutura simultaneamente, sem que ocorram conflitos entre os nomes, surgiu a tecnologia de Namespaces (espaos de nomes). Um documento utilizando esta tecnologia exemplificado na figura 3.
Neste documento, existe um artigo e um livro, cada um com seus respectivos dados. O valor do atributo xmlns denominado URI, que ser mais claramente apresentado adiante. Cada um dos elementos filhos do elemento publicacao que se inicia na linha 2, incluindo ele prprio, possui sua URI igual a http://schuenck/art, e por isto, segue a estrutura indicada pela namespace identificada por este nome. No caso do elemento publicacao com incio na linha 9, seus elementos esto de acordo com a namespace identificada por http://schuenck/liv. No caso de atributos, eles seguem o que est definido na namespace do seu respectivo elemento. Nota-se, no exemplo apresentado, que as duas ocorrncias do elemento local possuem conotaes diferentes. Na linha 6, local refere-se instituio onde foi realizado o evento no qual o artigo foi publicado, enquanto que, na linha 14, local refere- se cidade onde est situada a editora que publicou o livro. Em se tratando de XML, as namespaces so identificadas por IRIs, que so, na verdade, aprimoramentos de URIs a fim de suportar um conjunto maior de caracteres (NAMES, 2003). Assim, URIs e IRIs so nomes que identificam unicamente um recurso. Usualmente, eles tm o formato de URLs, mas isto no obrigatrio (BALLINGER, 2003). possvel utilizar, tambm, prefixos que simplificam o uso das namespaces, sendo definidos no elemento raiz. Um exemplo deste tipo de construo apresentado na figura 4. 21
1 <biblioteca xmlns:art=http://schuenck/art xmlns:liv=http://schuenck/liv xmlns=http://schuenck/bib> 2 <art:publicacao id=A1> 3 <art:autor>Marcus Barbosa</art:autor> 4 <art:titulo>Esquemas para XML</art:titulo> 5 <art:ano>2003</art:ano> 6 <art:local>CEULP/ULBRA</art:local> 7 <art:evento>ENCOINFO V</art:evento> 8 </art:publicacao> 9 <liv:publicacao id=L1> 10 <liv:autor>Keith Ballinger</liv:autor> 11 <liv:titulo>.NET Web Services: Architecture and Implementation</liv:titulo> 12 <liv:ano>2003</liv:ano> 13 <liv:editora>Addison-Wesley</liv:editora> 14 <liv:local>Boston</liv:local> 15 </liv:publicacao> 16 </biblioteca> Figura 4: Documento XML utilizando Namespace com prefixos
Na primeira linha informado que o prefixo art refere-se namespace definida por http://schuenck/art, que liv refere-se a http://schuenck/liv e que a URI padro http://schuenck/bib. Isto significa que, se algum elemento no for identificado com um prefixo, ser utilizada a namespace definida por http://schuenck/bib. A criao das estruturas que definem namespaces feita utilizando-se XML Schema, que ser o mote da prxima seo.
2.4 XML Schema
XML Schema uma tecnologia para representao de esquemas de dados XML recomendada pelo W3C em maio de 2001 (XSD, 2001A), representando uma alternativa importante DTD, que foi proposta no incio da utilizao de XML, e que bastante popular, sendo muito utilizada ainda. Suas principais caractersticas so as seguintes (PINTO, 2003): um documento XML. Determina os elementos e atributos que podem existir nos documentos por eles validados, bem como sua ordem. 22 Permite definio mais restrita de tipos de dados para elementos e atributos, em relao DTD. Determina a cardinalidade dos elementos, controlando a quantidade exata de ocorrncias de um elemento. Suporta a definio de tipos criados pelo usurio. Permite a reutilizao de cdigo (atravs da utilizao de namespaces). Possui grande compatibilidade com bancos de dados relacionais.
Nos exemplos que sero apresentados nas prximas sees, ser utilizado o prefixo xsd, que refere-se namespace representada pela URI http://www.w3.org/2001/XMLSchema, sendo que este o conjunto prefixo-URI normalmente utilizado em documentos XML Schema. A definio de elementos e atributos ser apresentada nas subsees a seguir.
2.4.1 Elementos
Elementos simples so definidos pelo elemento element, que utiliza os atributos name e type. Alm disso, pode-se definir restries atravs do uso dos elementos simpleType (ao invs de element) e restriction (XSD, 2001A). A figura 5 apresenta um exemplo que define dois elementos simples: nome e idade, podendo esta ltima ser menor que 130.
1 <xsd:element name=nome type=xsd:string/> 2 <xsd:simpleType name=idade> 3 <xsd:restriction base=xsd:positiveInteger> 4 <xsd:maxExclusive value=130/> 5 </xsd:restriction> 6 </xsd:simpleType> Figura 5: Elementos simples em XML Schema
Para a definio de elementos complexos utiliza-se o elemento complexType, que possui o elemento name para indicao do nome do elemento. Dentro deste elemento pode existir um elemento sequence, que possuir elementos do tipo element (XSD, 2001A), 23 vistos anteriormente. A figura 6 apresenta um exemplo da definio de elementos complexos.
1 <xsd:complexType name="Noticia"> 2 <xsd:sequence> 3 <xsd:element minOccurs="1" maxOccurs="1" name="id_noticia" type="xsd:int"/> 4 <xsd:element minOccurs="1" maxOccurs="4" name="titulo" type="xsd:string"/> 5 </xsd:sequence> 6 </xsd:complexType> Figura 6: Elemento complexo em XML Schema
Nas linhas 3 e 4 esto sendo definidos os elementos simples, que possuem os atributos minOccurs e maxOccurs. Estes permitem controlar a quantidade de ocorrncias dos elementos, sendo possvel a definio de qualquer nmero como o mnimo ou o mximo de ocorrncias, desde que o mximo seja maior ou igual ao mnimo. Para permitir que o mximo de ocorrncias seja ilimitado, utiliza-se maxOccus=unbounded. permitido o uso de trs tipos de delimitadores para definio da ordem dos elementos: sequence, visto anteriormente, que impe que a ordem dos elementos no documento deve ser aquela em que a definio dos elementos aparece no documento XML Schema; choice, em que apenas um dos elementos definidos poder existir no documento XML; e por fim, all, que diz que os elementos podem aparecer em qualquer ordem.
2.4.2 Atributos
Os atributos em XML Schema so definidos de forma semelhante aos elementos simples, porm, utilizando o elemento attribute, juntamente com os atributos name e type. possvel a utilizao de outros atributos no XML Schema, para funes especficas: use, que especifica a obrigatoriedade ou no de um atributo; fixed, para atributos com valor fixo; e default, para a definio de um valor padro. permitido ainda, especificar mais restries, atravs da utilizao dos elementos simpleType e restriction (XSD, 2001A). Um exemplo apresentado na figura 7.
1 <xsd:attribute name="idade"> 2 <xsd:simpleType> 3 <xsd:restriction base=xsd:integer> 24 4 <xsd:minInclusive value="0"/> 5 <xsd:maxInclusive value="130"/> 6 <xsd:restriction/> 7 </xsd:simpleType> 8 </xsd:attribute> Figura 7: Atributo em XML Schema
Considerando que o trecho apresentado na figura 7 est situado dentro de um complexType, ele tem a funo de definir um atributo cujo nome idade, que deve ser inteiro, cujo valor deve variar entre zero e cento e trinta.
2.4.3 Tipos de dados
Como visto nos exemplos anteriores, XML Schema define uma grande restrio aos tipos de dados dos elementos e atributos. Os tipos de dados se dividem principalmente em tipos complexos (definidos pelo usurio, como elementos complexos) e tipos simples. Entre os tipos simples, alguns exemplos so: time, date, boolean, float, decimal, double, base64binary. Uma tipagem forte dos dados permite maior compatibilidade dos dados apresentados em documentos XML, por linguagens de programao e outras tecnologias, como o caso dos dados representados por SOAP, por exemplo, ser visto na prxima seo.
2.5 SOAP
O protocolo SOAP um padro aberto que foi concebido em 1999, como uma recomendao do W3C, originada da proposta conjunta da Microsoft, IBM e Userland.com, entre outras empresas, sendo baseado nas especificaes da XML-RPC, criada por David Winer, da Userland.com, em 1998 (AMUNDSEN, 2002). Neste trabalho ser tomada como base, a verso 1.1 do SOAP, porm j existe uma recomendao da verso 1.2, do W3C. Assim, diferenas entre as duas verses tambm estaro sendo evidenciadas. 25 Embora tenha sido projetado para ser utilizado sobre vrios protocolos de transporte da Internet, tais como SMTP e TCP (MSDN, 2003B), o protocolo SOAP muito utilizado com o protocolo HTTP (JORGENSEN, 2002). A problemtica a ser solucionada pelo SOAP baseia-se no fato de que, em tratando- se de aplicaes Web convencionais, os dados transportados que eram padronizados, com o uso do protocolo HTTP, eram apenas a URL, o verbo HTTP (GET ou POST) e o cabealho HTTP. As demais informaes dependiam das estruturaes especficas de cada servidor Web. Por outro lado, em tratando-se de comunicaes entre aplicaes de diferentes plataformas, existe a necessidade de um idioma comum, para que seja possvel a comunicao entre os servidores (JORGENSEN, 2002). Assim, o SOAP funciona como este idioma comum, j que seu objetivo bsico utilizar a XML como forma de descrever informaes de bibliotecas de tipos (AMUNDSEN, 2002), possibilitando a comunicao entre duas extremidades, dois servidores, sem a dependncia de sistemas operacionais especficos. A troca de mensagens com SOAP ilustrada pela figura 9.
Figura 9: Etapas na comunicao entre servidores
Na figura 9, a comunicao representada pela seta de nmero um significa que o servidor A enviou uma solicitao em formato SOAP, pedindo informaes sobre biblioteca de tipos ao servidor B, o qual responde ao servidor A na segunda seta. A seta de nmero trs indica que o servidor A envia uma chamada a um mtodo, devidamente formatado em um envelope SOAP. Em seguida, o servidor B responde, na quarta seta, com um envelope SOAP que contm os resultados da execuo do mtodo anteriormente solicitado. O protocolo SOAP definido por trs partes: o envelope, as regras de codificao e a representao de RPC, os quais sero apresentados nas prximas trs sees. 26
2.5.1 Envelope SOAP
As mensagens SOAP so representadas por envelopes SOAP, que tm a funo de dizer o que tem na mensagem e para quem ela destinada. Os envelopes, por sua vez, so constitudos por um cabealho (header) e por um corpo (body) (SOAP, 2000). Um exemplo esquemtico apresentado na figura 10.
Figura 10: Representao de um envelope SOAP (MSDN, 2003B)
Sendo uma mensagem SOAP um documento XML, o envelope representado por um elemento envelope, que obrigatoriamente deve estar na mensagem SOAP. Ele pode conter um atributo encodingStyle, que representado por uma URI que indica as regras para a desserializao da mensagem SOAP (SOAP, 2000). Como elemento filho de envelope, pode existir um elemento Header, que define atributos a serem utilizados por seus elementos filhos. Estes atributos so utilizados para a indicao do destinatrio, representado pelo atributo actor (role, na verso 1.2 de SOAP) e da obrigatoriedade ou no do cabealho ser processado pelo destinatrio, representado pelo atributo mustUnderstand. Os elementos filhos de Header so chamados blocos de cabealho (SOAP, 2000). importante destacar que o termo destinatrio, mencionado anteriormente, refere-se ao servidor para o qual a mensagem destinada, o que significa que a mensagem no ser processada por servidores intermedirios, os roteadores. 27 Outro elemento filho obrigatrio de envelope Body, que deve estar localizado imediatamente depois do elemento header, caso ele exista. Os elementos filhos imediatos de Body so chamados blocos de corpo, nos quais podem ser definidos atributos encodingStyle, que so usados para indicar as regras de desserializao dos dados (SOAP, 2000). Tanto os blocos de cabealho quanto os blocos de corpo devem ser qualificados atravs de namespaces (SOAP, 2000). Por definio, um exemplo de envelope SOAP pode ser exemplificado pela figura 11.
A mensagem apresentada na figura 11, o cabealho constitudo por dois blocos de cabealho: AuthHeader, e Context. O primeiro contm os elementos UserName e Pwd, o que sugere que esta mensagem tem o objetivo de realizar uma autenticao. O atributo soap:actor="http://theFirewall define que o destinatrio desta mensagem representado pela URI http://theFirewall. O bloco de cabealho identificado pelo elemento Context possui o atributo soap:mustUnderstand="true, que significa que todo o contedo presente no cabealho deve ser processado pelo destinatrio. Esta mensagem possui apenas um bloco de corpo, Alert, cujo contedo Melissa is online!.
28 2.5.1.1 SOAP Fault
SOAP prov uma forma para reportar erros ocorridos no processamento de suas mensagens. Este mecanismo representado pelo elemento Fault, que deve ser filho de Body, sendo constitudo pelos seguintes elementos filhos (SOAP, 2003), segundo a verso 1.2 do SOAP: Code (representado pelo elemento faultcode, da verso 1.1): apresenta um cdigo para retratar computacionalmente o erro ocorrido, sendo obrigatrio um elemento filho Value, e opcional, um elemento Subcode, que possui um elemento filho obrigatrio Value e um outro filho opcional Subcode. Reason (representado pelo elemento faultstring, da verso 1.1): tem a funo de exibir uma mensagem entendvel pelo usurio. constitudo por um ou mais elementos Text, que apresenta o texto referente ao erro. Detail (representado pelo elemento detail, na verso 1.1): apresenta detalhes, na forma de elementos filhos, sobre o erro. Ele apresentado caso o erro tenha ocorrido no processamento do elemento Body. Node (correspondente ao elemento actor, na verso 1.1): identifica o elemento da mensagem SOAP onde ocorreu o erro.
Um exemplo de envelope SOAP indicando um erro no processamento da mensagem apresentado na figura 12.
possvel notar no exemplo da figura 12, a representao de um erro, definido pelo elemento Fault, com os elementos Code, Reason e Detail.
2.5.2 Regras de codificao
Pode-se dizer que as regras de codificao SOAP tm a utilidade de direcionar a converso dos contedos que so originalmente expressos em linguagens de programao, para o formato XML, de forma a seguir o formato do protocolo SOAP (BALLINGER, 2003). Esta converso permite que os objetos sejam transportados via Internet, utilizando protocolo HTTP. Desta forma, as regras para a codificao podem ser resumidas nos seguinte itens (SOAP, 2000): 1. Valores simples, de tipos especficos como strings e inteiros, so representados como valores de elementos, ou seja, um character data. O tipo do dado pode ser explicitado de trs maneiras: atravs de um atributo indicando o tipo, estando o elemento dentro de um elemento que representa um array, ou de uma forma que o nome do elemento j identifica o tipo do dado por ele contido. 2. Valores compostos, tal como endereos, por exemplo, so representados como seqncias de elementos. 3. Arrays contidos em estruturas so descritos por elementos complexos com todos os valores do array como elementos filhos. Alm disto, o novo elemento conter um atributo id, do tipo ID, que funcionar como uma chave estrangeira pela declarao do array, relacionando-se com um atributo href do elemento que representa o array.
30 Considerando a classe apresentada na figura 13, expressa na linguagem C#, apresentando uma classe Address, o resultado da sua codificao representado pela figura 14.
1 public class Address 2 { 3 Public String[] Street; 4 Public String City; 5 Public String State; 6 Public String ZipCode; 7 } Figura 13: Classe a ser codificada (BALLINGER, 2003)
No procedimento procedimento de codificao apresentado nas figuras 13 e 14, a classe Address tornou-se um elemento complexo com os contedos de seus atributos expressos como elementos simples. Seguindo o exposto no terceiro item, no caso do atributo Street, que um array, tornou-se um elemento vazio, com o atributo href referenciando o id do elemento soapenc:Array, criado aps o elemento Address, com as duas ruas constantes deste array.
2.5.3 Serializao XML
O processo de serializao XML consiste da utilizao de recursos de programao para a transformao de dados de objetos para o formato XML, permitindo o transporte sobre a Internet. Ou seja, a serializao permite que classes sejam mapeadas para esquemas XML e que instncias de objetos sejam mapeadas para instncias XML do seu esquema 31 correspondente (BALLINGER, 2003). Para tanto, a serializao XML segue as regras de codificao definidas anteriormente. Na plataforma .NET, a classe utilizada para a serializao XMLSerializer, que oferece mtodos para serializao, antes do envio dos dados, e desserializao, que o processo realizado quando os dados chegam ao destino e precisam voltar ao formato de objetos (MSDN, 2003D). Porm, o processo de serializao possui algumas particularidades, tal como a possibilidade de serializar apenas propriedades e atributos pblicos. Alm disso, ele no inclui informaes sobre tipos abstratos de dados, no garantindo assim, que objetos sejam deserializados para seus tipos de dados originais (MSDN, 2003D). Este servio normalmente oferecido pelas plataformas que implementam Web Services. Assim, a serializao realizada automaticamente para retornar os dados, no formato SOAP, referentes execuo de cada mtodo invocado.
2.5.4 SOAP RPC
Para que invocaes a mtodos possam ser transportadas, necessria a formatao dos dados envolvidos segundo o protocolo SOAP. Assim, esta seo apresentar como os dados dos mtodos devem ser organizados nas mensagens SOAP. O estilo do mecanismo de chamada a mtodos do SOAP parecido com o estilo de tecnologias como CORBA e RMI, porm, de forma mais simplificada (BALLINGER, 2003). Para que um mtodo possa ser chamado, necessria a URI do objeto de destino, o nome do mtodo, os parmetros do mtodo com seus respectivos tipos, e opcionalmente, a assinatura do mtodo e dados adicionados ao elemento Header da mensagem (SOAP, 2000). Desta forma, para que o mtodo definido em C# por public Address SubmitAddress(Address addr, bool dontSave), seja chamado, necessrio utilizar a representao mostrada na figura 15.
possvel perceber, entre as linhas 3 e 6, o elemento SubmitAddress, que representa o mtodo que se deseja executar, tendo como seus elementos filhos, os parmetros dontSave, do tipo boolean, e addr, referente classe Address, que especificada atravs do elemento Address, conforme as regras de codificao do SOAP. 2.5.5 Ligao entre HTTP e SOAP
SOAP passvel de ser implementado sob vrios protocolos de transporte. Porm, normalmente implementado para trabalhar com o protocolo HTTP, e por isto sero apresentados aspectos gerais do trabalho conjunto destes dois protocolos. HTTP um protocolo para transferncia de informaes de Web Sites. Por isto, nas requisies realizadas, o protocolo inclui nos cabealhos das mensagens, vrias informaes, dentre as quais, algumas sobre formatos que o cliente suporta (SOARES, 1995). No trabalho com Web Services, o protocolo HTTP inclui em suas mensagens o contedo SOAP. Assim, como o modelo de funcionamento permite que pares de solicitao/resposta sejam automaticamente correlacionados, atravs dos dados definidos pelo protocolo HTTP, possvel a uma aplicao de Web Services, decidir por processar ou no a mensagem recebida (SOAP, 2003). Ou seja, quando uma mensagem enviada, 33 passa por servidores intermedirios, caso o destinatrio especificado no cabealho HTTP seja o host atual, este a processa, caso contrrio, a mensagem prossegue em sua rota. Um exemplo do uso do protocolo HTTP para uma requisio SOAP apresentado na figura 16.
Entre as linhas 1 e 5, est colocado o cabealho HTTP, onde possvel identificar que esta uma mensagem de requisio, atravs de POST, na primeira linha, que tambm indica o recurso para o qual a mensagem destinada, e a verso do protocolo HTTP. A segunda linha identifica o nome do host de destino. A terceira indica o tipo de contedo, que, segundo a especificao do SOAP, obrigatrio que seja igual a text/xml (SOAP, 2000). A terceira linha define ainda, o tipo de codificao de caracteres, no caso, UTF-8. A linha preenchida com o tamanho do contedo da mensagem, e SOAPAction, na quinta linha, define o mtodo que ser invocado na mquina remota. Conforme a especificao de SOAP RPC, as linhas de 10 a 12 indicam o mtodo e seu parmetro. Uma possvel resposta a esta requisio apresentada na figura 17.
1 HTTP/1.1 200 OK 2 Content-Type: text/xml; charset=utf-8 3 Content-Length: nnnn 4 5 <?xml version="1.0" encoding="utf-8"?> 6 <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> 34 7 <soap:Body> 8 <NoticiaPorIDResponse xmlns="http://nds03/tcc"> 9 <NoticiaPorIDResult> 10 <id_noticia>10</id_noticia> 11 <titulo>30 anos da ULBRA</titulo> 12 <resumo>A Universidade Luterana do Brasil comemora os seus 30 anos.</resumo> 13 </NoticiaPorIDResult> 14 </NoticiaPorIDResponse> 15 </soap:Body> 16 </soap:Envelope> Figura 17: Resposta SOAP utilizando HTTP
Na resposta, o cabealho HTTP contm menos informaes, at mesmo porque, cada resposta relacionada pelo protocolo, a sua respectiva requisio. Assim, na mensagem de resposta, no existem os campos host, nem SOAPAction. Os dados referentes ao retorno do mtodo esto entre as linhas 9 e 13.
2.6 HTTP-GET e HTTP-POST
Alm do protocolo SOAP, tambm utilizado o prprio protocolo HTTP, atravs de seus verbos GET e POST, para a representao dos dados a serem trocados. Uma das diferenas entre estes protocolos e o SOAP, sua funcionalidade limitada, no sentido de que os dados transportados so baseados em pares nome/valor (PAYNE, 2001). Desta forma, apenas SOAP consegue transportar tipos de dados mais complexos, tal como classes, por exemplo. Por outro lado, em comunicaes envolvendo grandes volumes de dados ou em situaes em que existe escassez de recursos computacionais, a utilizao dos protocolos HTTP-GET e HTTP-POST mais recomendada, j que, por agregarem menos dados, garantem maior desempenho. A principal caracterstica do protocolo HTTP-GET o fato de as requisies acrescentarem pares nome/valor referentes a parmetros na prpria querystring (PAYNE, 2001). Um exemplo de requisio utilizando HTTP-GET apresentado na figura 18.
1 GET /tcc/noticia.asmx/NoticiaPorID?id_noticia=10 HTTP/1.1 2 Host: nds03 Figura 18: Requisio HTTP-GET 35
Pode-se notar na primeira linha, os termos destacados referem-se a um par nome/valor, que so adicionados querystring referente ao mtodo NoticiaPorID. A resposta a esta solicitao apresentada na figura 19.
1 HTTP/1.1 200 OK 2 Content-Type: text/xml; charset=utf-8 3 Content-Length: nnnn 4 5 <?xml version="1.0" encoding="utf-8"?> 6 <NoticiaDetalhe xmlns="http://nds03/tcc"> 7 <id_noticia>10</id_noticia> 8 <titulo>30 anos da ULBRA</titulo> 9 <resumo>A Universidade Luterana do Brasil comemora os seus 30 anos.</resumo> 10 </NoticiaDetalhe> Figura 19: Resposta HTTP-GET
Como se pode notar, o resultado da execuo do mtodo, utilizando-se o protocolo HTTP-GET apresenta maior simplicidade que aquele retornado pelo protocolo SOAP, apresentado na figura 17. Entre as linhas 1 e 3 est disposto o cabealho HTTP. A linha 5 identifica que os dados seguem a verso 1.0 da XML e que o esquema de codificao de caracteres utilizado o UTF-8. Entre as linhas 6 e 10 esto os dados resultantes da execuo do mtodo NoticiaPorID, que possui um elemento raiz NoticiaDetalhe, com os elementos atmicos id_noticia, titulo e resumo. A requisio via protocolo HTTP-POST caracterizada pela disposio dos parmetros diretamente na mensagem de solicitao, e no na querystring, conforme faz o HTTP-GET (PAYNE, 2001). Assim sendo, um exemplo de solicitao HTTP-POST apresentado na figura 20.
1 POST /tcc/noticia.asmx/NoticiaPorID HTTP/1.1 2 Host: nds03 3 Content-Type: application/x-www-form-urlencoded 4 Content-Length: nnnn 5 6 id_noticia=10 Figura 20: Requisio HTTP-POST
36 As linhas 1 e 4 apresentam o cabealho HTTP referente solicitao, e na linha 6, colocado o nome do parmetro e o seu valor, para que o mtodo NoticiaPorID, explicitado na primeira linha, possa ser executado. A resposta para esta requisio a mesma do protocolo HTTP-GET, que apresentada na figura 19. importante destacar que a escolha de qual protocolo utilizar feita pelo consumidor do Web Service. No momento da criao do Web Service, o desenvolvedor no precisa se preocupar com este item, j que os documentos WSDL, que sero apresentados na prxima seo, descrevem as formas de comunicao atravs dos trs tipos de protocolos.
2.7 WSDL
Antes que as comunicaes via Web Services sejam iniciadas, necessrio que a mquina que vai consumi-los tenha conhecimento dos formatos de mensagens que sero enviadas e recebidas do servidor. Para este fim, foi criada a WSDL (WSDL, 2003), que uma linguagem baseada em XML, para a representao das funcionalidades de um Web Service. A estrutura dos documentos WSDL divide-se em uma parte abstrata, representada pelos elementos types, message e portType, e por uma parte concreta, representada pelos elementos binding e service. Nas sees abstratas so descritos os dados e as operaes suportadas pelo Web Service, enquanto que nas sees concretas so definidas informaes concretas para a realizao das operaes oferecidas (BALLINGER, 2003). Todos estes elementos so colocados como filhos do elemento raiz, definitions, seguindo a mesma ordem com que foram apresentados. Como documentos WSDL utilizam namespaces, a declarao do elemento definitions feita conforme apresentado na figura 18.
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://nds03.org/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" target="http://nds03.org/" xmlns="http://schemas.xmlsoap.org/wsdl/"> Figura 18: Elementos message em um documento WSDL 37
Os exemplos apresentados nas sees 2.3.1, 2.3.2, 2.3.3, 2.3.4 e 2.3.5 so referentes descrio de um Web Service que possui um mtodo noticiasCursos, que tem a funo de retornar um objeto Noticia.
2.7.1 Elemento types
O elemento types responsvel por definir um esquema para os dados que sero trafegados nas requisies e respostas dos mtodos. A linguagem padro utilizada para a representao deste esquema XML Schema (WSDL, 2003). Um exemplo da utilizao deste elemento em um documento WSDL apresentado na figura 19.
Um aspecto importante deste exemplo est na linha 2, em que existe um atributo chamado target, cujo valor igual a http://nds03.org. Isto significa que a namespace definida por http://nds03.org conter os nomes que sero definidos nesta seo (SIDDIQUI, 2001), permitindo a sua utilizao nas sees seguintes do documento 38 WSDL, atravs do prefixo s0, que est declarado no elemento definitions (vide figura 18). possvel a utilizao de outras linguagens de representao de esquemas, desde que a estrutura dos elementos do esquema estejam identificados atravs das namespaces correspondentes (WSDL, 2003). 2.7.2 Elementos message
Os elementos message definem formatos abstratos para os dados que so enviados (valor do atributo name possui o sufixo In) ou recebidos (valor do atributo name possui o sufixo Out) pelos Web Services (WSDL, 2001). Em outras palavras, pode-se dizer que elementos message representam os parmetros dos mtodos (SIDDIQUI, 2001), comumente chamados de operaes, em termos de WSDL. Estes elementos so compostos por elementos part, nos quais estabelecida uma ligao com a seo types, atravs do atributo element. Exemplos da utilizao destes elementos so exibidos na figura 20.
No exemplo apresentado, esto representados os tipos de parmetros e os tipos de retornos possveis para cada um dos protocolos utilizados pelo Web Service em questo.
39 2.7.3 Elementos portType
Os elementos portType representam conjuntos abstratos de operaes que so suportadas pelo Web Service. Estas operaes so definidas concretamente atravs dos elementos binding, cuja ligao estabelecida atravs do atributo type, de binding, e name, de portType (SIDDIQUI, 2001) (WSDL, 2001). Alm disto, estes elementos relacionam os pares requisio-resposta definidos anteriormente, nos elementos message, atravs de atributos message (MSDN, 2003E). Na verso 2.0 da WSDL, os elementos portType foram renomeados para interfaces (WSDL, 2003). A figura 21 apresenta um exemplo da utilizao destes elementos.
Pode-se notar a existncia de trs elementos portType, equivalentes a cada um dos protocolos envolvidos: SOAP, HTTP-GET e HTTP-POST. 2.7.4 Elementos binding
Os elementos binding apresentam informaes concretas referentes a respectivos portType, sobre o protocolo que ser utilizado no transporte das mensagens, sobre os formatos das mensagens (WSDL, 2001) e sobre a operao a ser executada (MSDN, 2003E). Como elemento filho de binding, existir um elemento que definir o protocolo 40 utilizado. Este o caso dos elementos soap:binding e http:binding, nas linhas 2 e 10 da figura 22, por exemplo.
Na linha 2, o atributo transport="http://schemas.xmlsoap.org/soap/http" diz que para o transporte das mensagens ser utilizado o protocolo HTTP. Entre as linhas 3 e 6, declarada a operao cujo nome noticiasCursos, que, na linha 4, definido que a ao a ser executada via SOAP definida pela URI http://nds03.org/noticiasCursos. Alm disso, nas linhas 5 e 6 so definidos os tipos de entradas e sadas para a execuo da operao definida na linha 4, utilizando-se SOAP. Situaes equivalentes ocorrem nos demais elementos binding, que utilizam o protocolo HTTP, com seus verbos GET e POST.
2.7.5 Elemento service
41 O elemento service um conjunto de elementos port relacionados, os quais se referem a elementos binding previamente definidos e que definem o endpoint atual, ou seja, o endereo lgico do Web Service (SIDDIQUI, 2001). A figura 23 apresenta um exemplo de elemento service.
1 <service name="Noticias"> 2 <port name="NoticiasSoap" binding="s0:NoticiasSoap"> 3 <soap:address location="http://nds03/tcc/teste.asmx" /> 4 </port> 5 <port name="NoticiasHttpGet" binding="s0:NoticiasHttpGet"> 6 <http:address location="http://nds03/tcc/teste.asmx" /> 7 </port> 8 <port name="NoticiasHttpPost" binding="s0:NoticiasHttpPost"> 9 <http:address location="http://nds03/tcc/teste.asmx" /> 10 </port> 11 </service> Figura 23: Elementos service em um documento WSDL
Em resumo, pode-se dizer que a seo types define todas as estruturas que sero utilizadas pelo Web Service. Os elementos message definem os formatos dos dados trocados, ou seja, dos parmetros e dos retornos, atravs da utilizao das estruturas definidas no elemento types. Os elementos portTypes montam as estruturas dos mtodos, por meio dos elementos operations, que definem os nomes dos mtodos, alm de reunirem pares solicitao-resposta, atravs dos parmetros definidos nos elementos message. As sees binding estabelecem a ligao entre as estruturas dos mtodos, representadas pelos elementos portType, com as aes concretas que o Web Service suporta, definidas pelos elementos soap:operation e http:operation. Por fim, o elemento service define a localizao concreta do Web Service, alm de estabelecer ligaes com as operaes representadas pelos elementos binding.
2.8 UDDI
No processo de desenvolvimento de uma aplicao, pode ser necessria a utilizao de servios especficos, que muitas vezes encontram-se em localidades distantes, em empresas cujo nome o desenvolvedor nunca ouviu falar. Com a finalidade de facilitar a localizao de Web Services, foi criada a UDDI (UDDI, 2003). 42 Esta tecnologia surgiu como uma iniciativa conjunta da Microsoft, IBM e Ariba, em 2000, e caracterizada pela existncia de bancos de dados abertos, que permitem a busca e publicao de Web Services, atravs de seus meta-dados (BALLINGER, 2003), que so compostos de acordo com o protocolo UDDI (UDDI, 2003). Basicamente, existem duas formas de interao com os repositrios UDDI: Atravs de interface com usurio, oferecida pelos repositrios. Atravs destas interfaces, possvel a submisso de consultas manualmente, alm do preenchimento de todos os dados necessrios publicao de um Web Service, sem a necessidade de conhecimento sobre a criao de documentos UDDI. Algumas destas interfaces podem ser acessadas pelos seguintes endereos: http://uddi.ibm.com, http://uddi.microsoft.com, http://uddi.sap.com e http://www.ntt.com/uddi. Programaticamente, atravs de uma API de programao. As funcionalidades desta API podem ser divididas em dois tipos: funes de investigao, responsveis por recuperao de informaes sobre servios, agregando as seguintes operaes: find_binding, find_business, find_service, find_tModel, get_bindingDetail, get_businessDetail, get_BusinessDetailExt, get_serviceDetail e get_tModelDetail (BALLINGER, 2003); e funes de publicao, responsveis por realizar operaes referentes publicao de servios em repositrios UDDI, compostas pelas seguintes operaes: save_binding, save_business, save_service, save_tModel, delete_binding, delete_business, delete_service, delete_tModel, get_authToken, discard_authToken e get_registeredInfo (UDDI, 2002). Com base no exposto, pode-se dizer, que o ciclo para o consumo de um Web Service inicia-se com a descoberta dos servios que sero utilizados, que realizada ainda em tempo de projeto. Por outro lado, a publicao a ltima etapa a ser realizada pelo projetista de Web Services. Assim, as primeiras etapas da criao do servio correspondem sua implementao efetiva, que ser apresentada na prxima seo.
2.9 Criao de Web Services da plataforma .NET
43 Na plataforma .NET as funcionalidades dos Web Services podem ser definidas em arquivos do tipo ASMX. Para tanto, podem ser utilizadas quaisquer linguagens de programao suportadas em .NET. Alm deste, um outro requisito necessrio para que as funcionalidades de um Web Service possam ser acessadas por outras aplicaes, que o arquivo ASMX esteja colocado em uma pasta virtual de um servidor Web que possua o IIS e a plataforma .NET instalada. Estas tarefas garantem que um Web Service esteja criado e disponvel para ser consumido por outros computadores. Adicionalmente, o desenvolvedor pode publicar seus Web Services em repositrios UDDI, com a finalidade de divulgar seus servios. Nas sees a seguir sero apresentados detalhes da criao de Web Services na plataforma .NET.
2.9.1 Arquivos ASMX
Os arquivos ASMX seguem a sintaxe dos programas escritos nas linguagens C#, Visual Basic .NET e JScript .NET (PAYNE, 2001). Porm, as principais diferenas dos arquivos ASMX so as seguintes (BALLINGER, 2003): A primeira linha possui uma diretiva WebService que deve ser composta da seguinte forma: <%@ WebService Language="C#" Class="NomeDaClasse" %> Possuem referncias s namespaces System e System.Web.Services. Neste caso, a palavra namespace possui significado diferente daquele apresentado na seo 2.3. Na plataforma .NET, namespaces referem-se a agrupamentos de classes, que so equivalentes aos pacotes em Java. So acrescentados atributos WebMethod nos mtodos das classes. Isto significa que os mtodos so passveis de serem invocados remotamente. Recomenda-se que sejam adicionados s declaraes das classes, o atributo WebService, com o objetivo de definir uma descrio e uma namespace referentes ao servio.
Um exemplo de arquivo ASMX, para a realizao de somas de dois valores apresentado na figura 24. 44
1 <%@ WebService Language="C#" Class="Soma" %> 2 3 using System; 4 using System.Web.Services; 5 6 [WebService(Description="WebService para soma de dois valores",="http://nds03/michael")] 7 public class Soma : WebService { 8 9 [WebMethod(Description="Soma entre dois valores float")] 10 public float somar(float valor1, float valor2) 11 { 12 return valor1 + valor2; 13 } 14 } Figura 24: Exemplo de arquivo ASMX
Na primeira linha, definido que este arquivo refere-se a um Web Service, que a linguagem utilizada C# e que a classe a ser tornada pblica Soma. Nas linhas 3 e 4, so importadas respectivamente as namespaces System e System.Web.Services. A linha 6 define o atributo WebService, em que so determinadas tambm a descrio do servio e um valor para a namespace, a qual corresponder ao atributo target, do documento WSDL referente a este servio. Na linha 7 definida a classe Soma, que herda da classe WebService, que se encontra na namespace System.Web.Services. Entre as linhas 9 e 12 definido um mtodo da Web, chamado somar, em que definida uma descrio, por meio da propriedade Description, e que recebe dois valores do tipo float e retorna o resultado da soma deles. Para o atributo WebMethod, as propriedades suportadas so as seguintes (PAYNE, 2001): BufferResponse: especifica se o retorno do mtodo ser armazenado em buffer no servidor, antes de ser enviado ao cliente. O valor padro true. CacheDuration: define o tempo pelo qual a resposta da execuo de um mtodo deve ser armazenada em cache. O valor padro 0. Description: define uma descrio do mtodo para o cliente, quando este acessa o arquivo ASMX atravs do navegador. EnableSession: especifica a ativao ou no do estado de sesso. ativado por padro. 45 MassageName: define o nome pelo qual o mtodo ser invocado, que normalmente definido pelo prprio nome do mtodo, porm til quando existem dois mtodos de mesma assinatura e funes diferentes. TransactionOption: determina o tipo de transao usada na execuo do mtodo. Os tipos de transao so: Disabled, NotSupported, Supported, Required, RequiresNew. TypeID: atributo herdado da classe Attribute, utilizado para identificar unicamente uma instncia de objeto desta classe.
Para a realizao de testes com os Web Services criados, pode-se acess-los atravs do browser, permitindo o conhecimento de seus componentes. Assim, a visualizao do arquivo apresentado exibida na figura 25.
Figura 25: Visualizao de um arquivo ASMX em um browser
Na figura 25 pode-se notar que o nome da classe criada Soma, a qual possui um mtodo chamado somar. Para acessar este mtodo, basta clicar sobre o link. Ser aberta uma nova janela para requerer os valores que so passados como parmetros para a execuo deste mtodo. Esta janela apresentada na figura 26.
46
Figura 26: Interface para insero dos parmetros do mtodo somar
Aps serem inseridos valores para os parmetros, pode-se invocar o mtodo clicando no boto Invoke. No caso dos testes realizados via navegador, utilizado o protocolo HTTP-POST para requisio e resposta. O resultado da execuo do mtodo retornado em XML, seguindo o formato HTTP-POST de resposta para este mtodo, conforme apresentado na figura 27.
47
Figura 27: Resultado da execuo do mtodo somar
Na figura 27, para apresentar a resposta criado um elemento float, cuja namespace aquela definida no elemento WebService, e cujo contedo o valor 25. Para o acesso ao documento WSDL que descreve este Web Service, adicionado, ao final do endereo do servio, na barra de endereos do navegador de Internet, o termo ?WSDL.
2.9.2 Autenticao de Web Services
Muitas vezes, os Web Services so criados com contrapartida financeira, com o intuito de oferecer servios como qualquer outro, incluindo a necessidade de pagamento. Para isto, necessrio que os Web Services sejam consumidos apenas por pessoas autorizadas. Com esta finalidade, so utilizadas entidades separadas, chamadas cabealhos de SOAP. Para a utilizao deste tipo de cabealhos, cria-se uma classe que herda da classe System.Web.Services.Protocols.SoapHeader, que servir para reunir as informaes de autenticao. Esta classe pode ser adicionada ao mesmo arquivo referente ao Web Service (PAYNE, 2001). A figura 28 apresenta um exemplo deste tipo de classe.
1 using System.Web.Services; 2 using System.Web.Services.Protocols; 3 4 public class Autenticacao : SoapHeader { 48 5 public string login; 6 public string senha; 7 } Figura 28: Classe para representao de cabealho de SOAP
Tendo sido criada uma classe Autenticacao, que herda de SoapHeader, declara-se uma instncia desta classe na classe que se deseja proteger. Cada mtodo a ser protegido deve ento, utilizar o atributo SoapHeader, que se utilizar da instncia criada (PAYNE, 2001). Alm disto, a classe de cabealho de SOAP representar informaes de autenticao de usurios como uma classe qualquer que possua esta finalidade. A estrutura da utilizao desta classe exemplificada na figura 29.
1 using System; 2 using System.Web.Services; 3 using System.Web.Services.Protocols; 4 5 public class Autenticacao : SoapHeader { 6 public string login; 7 public string senha; 8 } 9 10 public class ServicoSeguro : WebService { 11 public Autenticacao soapHeader; 12 13 [WebMethod()] [SoapHeader("soapHeader)] 14 public float somar(float valor1, floar valor2) 15 { 16 if((soapHeader.login == "michael) && (soapHeader.senha == "schuenck)) 17 return valor1 + valor2; 18 } Figura 29: Servio autenticado atravs de cabealho de SOAP
Os dois novos aspectos do exemplo mostrado na figura 29 so, na linha 16, o uso do atributo SoapHeader, e, nas linhas 19 e 20, a verificao dos dados da classe de cabealho de SOAP com os dados corretos, antes que as aes do mtodo sejam executadas. Na utilizao deste servio em uma aplicao qualquer, deve-se definir os valores dos atributos de uma instncia da classe Autenticacao, a qual deve ser atribuda ao atributo soapHeader, de uma instncia da classe ServicoSeguro (PAYNE, 2001). Caso as informaes sejam autenticadas, a invocao do mtodo somar realizada. 49 Tendo sido apresentadas as principais caractersticas da criao de Web Services, a prxima seo apresentar as metodologias para o consumo deles.
2.10 Consumo de Web Services na plataforma .NET
Na plataforma .NET, o consumo de Web Services pode ser realizado por aplicaes escritas em quaisquer das linguagens suportadas. Porm, para que os servios possam ser efetivamente utilizados nas aplicaes finais, so necessrias algumas etapas, que sero mostradas nas prximas sees.
2.10.1 Gerao da classe proxy
A gerao de uma classe proxy uma tarefa realizada automaticamente pela plataforma .NET, atravs do programa wsdl, que se utiliza do documento WSDL referente ao servio (PAYNE, 2001). Para a gerao da classe proxy do Web Service apresentado na figura 24, utiliza-se a seguinte instruo, na linha de comando:
wsdl http://nds03/tcc/soma.asmx?wsdl /out:soma.cs
Algumas das opes do comando wsdl so as seguintes: /language: tem a funo de definir a linguagem em que ser gerada a classe proxy. A linguagem padro C#. /: define um nome para a namespace na qual a classe proxy estar inserida. /protocol: define o protocolo que ser utilizado nas comunicaes do Web Service. As opes so HTTP-GET, HTTP-POST e SOAP, que o protocolo padro. /out: define o nome do arquivo que ser gerado.
A classe gerada com a execuo da instruo apresentada apresentada no anexo C. 50 Sendo criada a classe proxy, necessria a sua compilao, para que possa ser efetivamente utilizada pelas aplicaes que vo consumir os Web Services. Esta etapa ser apresentada na prxima seo.
2.10.2 Compilao da classe proxy
A compilao da classe proxy realizada com o compilador da linguagem na qual a classe foi gerada (PAYNE, 2001). Assim, programas escritos em C# so compilados com o programa csc, em VB .NET com o vbc e em Jscript .NET com o programa jsc. Para compilar a classe proxy gerada anteriormente, utiliza-se a seguinte instruo:
csc /target:library soma.cs
Esta instruo gera um arquivo chamado soma.dll, que dever ser referenciado quando da compilao do programa que ir consumir o Web Service. Um exemplo de programa consumidor, na linguagem C#, apresentado na figura 30.
1 using System; 2 class Consumidor { 3 public static void Main(String[] args){ 4 Soma soma = new Soma(); 5 float a = 5; 6 float b = 20; 7 Console.WriteLine("O valor da soma : {0}",soma.somar(a,b).ToString()); 8 } 9 } Figura 31: Aplicao C# invocando o mtodo somar do Web Service da figura 24
Esta uma aplicao console, que possui uma classe Consumidor, cujo mtodo principal responsvel por instanciar um objeto da classe Soma, e apresentar o resultado da invocao do mtodo somar, em que so passados dois valores float como parmetros. Para a compilao desta aplicao utilizada a seguinte instruo.
csc /reference:soma.dll Consumidor.cs
Como se pode notar, em aplicaes console no utilizada nenhuma referncia classe proxy no prprio cdigo. No caso de aplicaes Web, necessrio que o arquivo .dll 51 gerado pela compilao seja colocado em um diretrio chamado bin, filho do diretrio que conter as pginas que se utilizaro do Web Service. Neste caso, a compilao da classe proxy dever ser realizada atravs da instruo apresentada abaixo.
csc /target:library /out:.\bin\soma.dll soma.cs
Alm das opes apresentadas, o compilador de programas em C# possui vrias outras, que incluem outras formas de destino, gerao de documentos XML para documentao, habilitao de otimizaes, entre outras. Da mesma forma, os compiladores vbc e jsc, possuem inmeras opes de composio para as compilaes. A prxima seos apresentar alguns aspectos importantes envolvendo o desenvolvimento para aplicativos mveis, utilizando-se a plataforma .NET.
2.11 Dispositivos mveis baseados na plataforma Pocket PC
Um dos principais tipos de dispositivos mveis so os PDAs, que, apesar de se utilizarem de comunicaes sem fio, no necessitam de conexes contnuas para que possa ser utilizado, como o caso da tecnologia WAP, utilizada pelos telefones celulares (MSDN, 2003G). A Microsoft disponibiliza uma plataforma operacional para PDAs, chamada Pocket PC, que se encontra na verso 2003 e utiliza a plataforma .NET Compact, que um subconjunto da plataforma .NET para aplicaes desktop. Isto permite fcil transio para a programao para Pocket PC (MSDN, 2003G). A Microsoft oferece ainda, a ferramenta Visual Studio .NET 2003, que possibilita a criao de aplicaes para Pocket PC, alm de oferecer um emulador, que permite a realizao de testes, e que foi utilizado na implementao do trabalho apresentado neste relatrio. A tela principal do emulador vista na figura 32.
52
Figura 32: Tela principal do emulador de Pocket PC
Quando se pede para executar uma aplicao para Pocket PC, utilizando-se a ferramenta Visual Studio .NET 2003, o emulador automaticamente carregado com a aplicao desenvolvida, sem a necessidade de um dispositivo real para a realizao de testes. At mesmo pelo fato de constituir um subconjunto da plataforma .NET, a plataforma .NET Compact permite o desenvolvimento de aplicaes que utilizam a tecnologia de Web Services para a comunicao. Este um fator importante, j que, como existe uma certa limitao de recursos computacionais dos PDAs, motivada at mesmo pelo seus tamanhos, parte do processamento passa a ser funo de servidores remotos. Este captulo apresentou os itens tericos necessrios para a realizao do trabalho, cujos detalhes da implementao sero especificados no captulo 4, aps uma apresentao do material e mtodos utilizados para a concretizao deste trabalho. 53
3 MATERIAL E MTODOS
Neste captulo, sero apresentados os detalhes referentes aos materiais e metodologia utilizados na implementao da aplicao descrita no primeiro captulo, alm da utilizada no processo de desenvolvimento desta monografia.
3.1 Local e Perodo
O trabalho foi desenvolvido no NDS (Ncleo de Desenvolvimento de Software) e no Labin 5 (Laborattio de Informtica nmero 5) do Curso de Sistemas de Informao, no Centro Universitrio Luterano de Palmas. Os trabalhos tiveram incio no ms de agosto de 2003 e trmino em dezembro de 2003.
3.2 Material
O material utilizado podem ser divididos em trs categorias: hardware, software e fontes bibliogrficas. A primeira, constituda por dois computadores: o primeiro, com processador Intel Pentium IV com clock de 1,7 GHz, 256 Mb de memria RAM e HD com capacidade para 40 Gb, localizado no Labin 5; enquanto que o segundo, possuem processador Intel Pentium III com clock de 750 MHz, 128 Mb de memria RAM e HD com capacidade para 20 Gb. O primeiro ficou responsvel pelo armazenamento dos dados das notcias cadastradas, e pela criao e execuo da aplicao consumidora do Web 54 Service, que, por sua vez, estava localizado no segundo computador, sob a mesma rede do primeiro. Os softwares utilizados foram os seguintes: Microsoft Word, para a redao do relatrio. Microsoft Access, para a realizao de testes preliminares com Web Services Microsoft SQL Server, para o armazenamento das notcias. Microsoft .NET Framework 1.1, para execuo de testes sobre os Web Services. Microsoft .NET Framework SDK (English) 1.1, para referncia e utilizao das classes providas pela plataforma .NET. Microsoft Visual Studio .NET 2003, para construo da aplicao para dispositivos mveis, alm da execuo de testes utilizando-se o emulador por ele provido. Adobe Acrobat Reader, para a leitura de referncias bibliogrficas.
3.3 Metodologia
A implementao pode ser dividida na criao do banco de dados de notcias, na implementao do Web Service e da aplicao final para PDAs. A princpio o banco de dados foi criado em Microsoft Access, sobre o qual foram feitos testes iniciais sobre alguns Web Services experimentais. Posteriormente, os dados foram transferidos para o Microsoft SQL Server, utilizado pelo Web Service final. Sobre a implementao do Web Service, foram realizados alguns testes iniciais, sem envolver acesso a bancos de dados. Em seguida, foram criados alguns Web Services para o acesso aos dados residentes no banco criado em Microsoft Access. E, por fim, foi criado o Web Service final, que foi utilizado pela aplicao mvel. Quanto aplicao para PDAs, sua implementao s se iniciou aps uma primeira verso do Web Service final ter sido criado. Porm, no momento da criao da aplicao final, foram percebidas algumas necessidades de adaptaes no Web Service, o que era imediatamente realizado.
55
4 RESULTADOS E DISCUSSO
Como parte integrante do trabalho, foi implementado um software para funcionar em PDAs que utilizem a plataforma Pocket PC. Sua funo apresentar notcias gerais, dos cursos e da pastoral do CEULP/ULBRA. Estas notcias residem em uma base relacional SQL Server, e so acessadas pelo Web Service desenvolvido (que apresentado na seo 4.4), que encontra-se em uma outra mquina, na mesma rede local. Assim, o princpio do funcionamento da aplicao mvel a apresentao dos resultados da invocao dos mtodos do Web Service. Resumidamente, este modelo pode ser ilustrado pela figura 33.
Figura 33: Modelo utilizado na implementao
Mais detalhes dos componentes deste modelo sero apresentados nas sees a seguir.
56 4.1 Banco de dados de notcias
Para a organizao dos dados referentes s notcias, segundo um esquema relacional, foram utilizadas seis tabelas, com todos campos necessrios, armazenadas em um banco de dados SQL Server. A representao das tabelas, de seus campos e de seus relacionamentos, gerada pelo prprio SQL Server, apresentada na figura 34.
Figura 34: Esquema do banco de dados para armazenamento das notcias
A tabela tb_noticia responsvel pelo armazenamento das principais informaes referentes s notcias. A tabela tb_noticia_imagem armazena as informaes referentes s imagens que so apresentadas juntamente com as notcias. Para o relacionamento entre estas duas tabelas utiliza-se, como chave estrangeira, o campo id_noticia, da tabela tb_noticia_imagem, e, como chave primria, o campo id_noticia, da tabela tb_noticia. Para a identificao da categoria qual pertencem as notcias, existem trs tabelas auxiliares, tb_noticia_instituicao, tb_noticia_pastoral e tb_noticia_curso, que possuem campos id_noticia, que so chave estrangeira em relao chave primria id_noticia, da tabela tb_noticia. Existe ainda, a tabela tb_curso, que serve para armazenar informaes sobre os cursos representados apenas pelo campo id_curso, na tabela tb_noticia_curso. 57
4.2 Classe para acesso ao banco de dados
Como forma de facilitar o acesso aos dados armazenados no banco de dados, foi criada uma classe que representa os atributos e mtodos necessrios para acesso aos dados. Assim, no necessrio que, para cada WebMethod, sejam definidos objetos e demais instrues para que os dados sejam efetivamente consultados. Esta classe, assim como todos os demais artefatos definidos nesta arquitetura, foi definida utilizando-se a linguagem C#. A classe, chamada Banco, apresentada na figura 35.
1 using System; 2 using System.Data; 3 using System.Data.SqlClient; 4 5 public class Banco { 6 private String strConexao = "Server=LABIN501;DataBase=Noticias;uid=michael;pwd=tcc"; 7 private SqlConnection conexao; 8 private SqlCommand comando; 9 public SqlDataReader selectSQL(String strSelect) { 10 try { 11 conexao = new SqlConnection(strConexao); 12 comando = new SqlCommand(strSelect, conexao); 13 comando.Connection.Open(); 14 return comando.ExecuteReader(); 15 } 16 catch(SqlException) { 17 return null; 18 } 19 } 20 public void fecharConexao() { 21 comando.Connection.Close(); 22 } 23 } Figura 35: Classe Banco, usada para acesso ao banco de dados
Entre as linhas 1 e 3 so declaradas as namespaces que contm as classes que sero utilizadas. A classe Banco possui um mtodo chamado selectSQL, para o qual passado como parmetro, um objeto da classe String, e que tem a funo de retornar um objeto da classe SqlDataReader. Para isto, so utilizados trs objetos privados, declarados entre as 58 linhas 6 e 8, sendo que os dois primeiros, strConexao e conexao, so utilizados para o estabelecimento da conexo com o banco, e o terceiro, chamado comando, da classe SqlCommand, representar a execuo SQL da string de consulta passada como parmetro, sobre a conexo estabelecida previamente. Entre as linhas 10 e 18 existe um bloco try-catch, que funciona como mecanismo para tratamento de excees. Assim, se ocorrer algum problema na execuo das instrues necessrias para que o mtodo seja executado corretamente, o mtodo retorna null, caso contrrio, ser retornado um objeto da classe SqlDataReader que represente os dados da consulta SQL. Os WebMethods do Web Service desenvolvido, no entanto, no retornam simplesmente o resultado da execuo do mtodo selectSQL: os resultados so adicionados em um array de objetos da classe Noticia e NoticiaDetalhe, que sero apresentadas na prxima seo.
4.3 Classes para representao das noticias
Foram criadas duas classes para representao das notcias: Noticia e NoticiaDetalhe. A primeira responsvel pela representao dos campos id_noticia e titulo, da tabela tb_noticia, enquanto que a segunda representa todos os dados que sero necessrios para a aplicao para dispositevos mveis. Na figura 36 apresentada a classe Noticia.
1 public class Noticia { 2 private int _id_noticia; 3 private string _titulo; 4 public Noticia(){ } 5 public Noticia(int Id_noticia, string Titulo){ 6 this._id_noticia=Id_noticia; 7 this._titulo=Titulo; 8 } 9 public int id_noticia { 10 get { 11 return _id_noticia; 12 } 13 set { 14 _id_noticia = value; 15 } 16 } 17 public string titulo { 59 18 get { 19 return _titulo; 20 } 21 set { 22 _titulo = value; 23 } 24 } 25 } Figura 36: Classe Noticia, usada para representar notcias
Nas linhas 2 e 3 so definidos os atributos _id_noticia e _titulo, que so respectivamente dos tipos inteiro e string. Entre as linhas 5 e 8 definido um mtodo construtor, que tem a funo de receber dois valores e atribu-los aos atributos definidos anteriormente. Entre as linhas 9 e 24 so definidas propriedades, para gravao e leitura dos respectivos atributos. A existncia de um mtodo construtor padro, definido na linha 4, de uso obrigatrio para que a classe possa ser utilizada pelo Web Service. Da mesma forma que foi definida a classe Noticia, a classe NoticiaDetalhe segue a mesma estrutura, porm, possuindo os seguintes atributos: _id_noticia, do tipo inteiro; _titulo, do tipo string; _resumo, do tipo string; _texto_plano, do tipo string; e _img_big, que um array de bytes. Estas duas classes so utilizadas pelo Web Service criado, que ser visto na seo a seguir.
4.4 Classe para representao do Web Service
O Web Service criado, cujo nome de classe Noticias, possui quatro WebMethods: NoticiasDosCursos: retorna um objeto da classe ArrayList, contendo objetos da classe Noticia, cujos dados atendem aos seguintes requisitos: de serem notcias de cursos, ou seja, que as notcias retornadas tenham o valor do seu campo id_noticia cadastrado na tabela tb_noticias_cursos; e que a data atual seja maior ou igual ao campo data_inicial e menor ou igual ao campo data_final da tabela tb_noticia. 60 NoticiasDaPastoral: retorna um objeto da classe ArrayList, contendo objetos da classe Noticia, cujos dados atendem aos seguintes requisitos: de serem notcias da pastoral, ou seja, que as notcias retornadas tenham o valor do seu campo id_noticia cadastrado na tabela tb_noticias_pastoral; e que a data atual seja maior ou igual ao campo data_inicial e menor ou igual ao campo data_final da tabela tb_noticia. NoticiasDaInstituicao: retorna um objeto da classe ArrayList, contendo objetos da classe Noticia, cujos dados atendem aos seguintes requisitos: de serem notcias da instituio, ou seja, que as notcias retornadas tenham o valor do seu campo id_noticia cadastrado na tabela tb_noticias_instituicao; e que a data atual seja maior ou igual ao campo data_inicial e menor ou igual ao campo data_final da tabela tb_noticia. NoticiaPorID: recebe como parmetro, o valor id_noticia, da notcia cujos detalhes se pretende recuperar, retornando um objeto da classe NoticiaDetalhe.
O mtodo NoticiasDaInstituicao apresentado na figura 37. Os outros dois mtodos que retornam objetos da classe ArrayList, seguem estruturas semelhantes, alterando-se apenas a string SQL para a consulta.
1 [WebMethod(Description="Retorna a lista de notcias dos cursos")] 2 [SoapRpcMethod] 3 public ArrayList NoticiasDaInstituicao(){ 4 ArrayList lista = new ArrayList(); 5 DateTime dt = DateTime.Now; 6 Banco banco = new Banco(); 7 SqlDataReader reader = banco.selectSQL("SELECT n.id_noticia, n.titulo, n.resumo, n.texto_plano, nim.img_big FROM tb_noticia_instituicao ni INNER JOIN tb_noticia n ON ni.id_noticia = n.id_noticia INNER JOIN tb_noticia_imagem nim ON n.id_noticia = nim.id_noticia WHERE (n.data_inicial <= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') AND (n.data_final >= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') ORDER BY n.id_noticia DESC"); 8 banco.fecharConexao(); 9 if(reader != null){ 10 while(reader.Read()){ 11 noticia = new Noticia(reader.GetInt32(0), reader["titulo"].ToString()); 12 lista.Add(noticia); 13 } 14 } 15 return lista; 16 } Figura 37: WebMethod NoticiasDaInstituicao 61
A primeira linha especifica que o mtodo trata-se de um WebMethod, cuja descrio est explicitada. A linha 2 identifica que esta trata-se de uma chamada remota a um mtodo, informao requerida pela aplicao que utilizar o mtodo. Entre as linhas 4 e 7 so instanciados os objetos que sero utilizados pelo mtodo. Na verdade, estes objetos so atributos privados do Web Service, mas foram colocados desta forma no exemplo para melhor visualizao. Na linha 7, o resultado da consulta em SQL armazenado em um objeto da classe SqlDataReader. Ento, caso o contedo deste objeto no seja nulo, seus registros so armazenados em objetos da classe Noticia, para posterior adio ao ArrayList, processo que realizado entre as linhas 8 e 13. Por fim, a linha 14 retorna o objeto lista, da classe ArrayList. Executando-se o mtodo NoticiasDaInstituicao atravs do navegador de Internet, o resultado apresentado na figura 38.
Figura 38: Resultado da execuo do mtodo NoticiasDaInstituicao
Apesar de vrios outros dados serem apresentados na aplicao mvel, apenas dois foram retornados: id_noticia e titulo. Para os demais dados, utilizado o mtodo NoticiaPorID. Assim, de posse do valor de um campo id_noticia, possvel invocar este mtodo para recuperao dos demais dados. 62 Esta foi a sada encontrada como forma de no carregar vrios dados que talvez no sejam necessrios, j que, conforme ser visto na prxima seo, na aplicao mvel so apresentados, primeiramente, apenas os ttulos das notcias. Assim, a partir do momento que o usurio escolher uma notcia para que seus detalhes sejam visualizados, todos os demais dados sero carregados, com a invocao do mtodo NoticiaPorID. Em dispositivos com limitaes de recursos, como o caso de PDAs, esta uma alternativa bastante usual. Todas as classes criadas no contexto deste trabalho e vistas at aqui foram armazenadas no mesmo arquivo, Noticia.asmx, cujo cdigo completo est disposto no Anexo A. A disposio de todas as classes necessrias no mesmo arquivo do Web Service usual, pois elimina a necessidade de compilao manual de cada um dos arquivos que seriam gerados. Aps terem sido vistas todas as partes necessrias ao correto funcionamento do Web Service, a prxima seo apresentar detalhes da criao da prpria aplicao criada para executar em PDAs.
4.5 A aplicao para dispositivos mveis
A aplicao criada para rodar em PDAs consiste basicamente de dois formulrios principais: um para exibio das notcias da categoria escolhida e um para exibio dos detalhes da notcia selecionada na parte anterior. O primeiro, o formulrio principal, designado pela classe FormConsumer, que composta por um objeto da classe ListView, da namespace System.Windows.Forms, que utilizado para apresentar os ttulos das notcias recuperadas pelos mtodos do Web Service apresentado anteriormente. Este objeto permite que um clique sobre o ttulo de uma notcia dispare um evento que chame o segundo formulrio. Alm disto, existe ainda no primeiro formulrio, um menu para a escolha da categoria de notcias e um boto para atualizar as notcias. A tela do emulador que apresenta esta parte ativa ilustrada na figura 39.
63
Figura 39: Tela do emulador exibindo os ttulos das notcias dos cursos
O menu apresenta os tipos de notcias existentes no banco de dados. Quando o usurio seleciona algum item do menu, invocado o mtodo do Web Service que recupera as informaes relativas ao respectivo item. Os ttulos das notcias recuperadas so ento, carregados no ListView. Como o tipo de retorno dos mtodos NoticiasDaInstituicao, NoticiasDosCursos e NoticiasDaPastoral um ArrayList contendo objetos da classe Noticia, necessria a utilizao do mtodo GetEnumerator, que retorna uma referncia interface IEnumerator, da namespace System.Collections. Esta necessidade deve-se ao fato da aplicao no entender automaticamente que o array trata-se de um ArrayList. Ou seja, apesar do WebMethod retornar um ArrayList, este objeto no reconhecido pela aplicao cliente, pois o ArrayList contm um tipo customizado, noticia. O carregamento dos ttulos das notcias no ListView feito por meio de um mtodo chamado preencherLV, existente na classe FormConsumer. Ele recebe valores inteiros que indicam a categoria de notcias e retorna um valor booleano indicando se existem itens no ListView. Este mtodo apresentado na figura 40.
Nota-se, entre as linhas 5 e 19, que os mtodos do Web Service so invocados dependendo do valor passado como parmetro. Assim, para qualquer que seja o valor passado como parmetro, utilizado o mtodo GetEnumerator para que o resultado da execuo do WebMethod correspondente seja devidamente adicionado em um objeto da classe ArrayList. Em seguida, se o ArrayList contendo as notcias no for nulo, seus itens so atribudos a um objeto da classe Noticia, para que possam ser adicionados ao ListView, o que feito entre as linhas 22 e 27. A classe FormConsumer apresentada na ntegra no Anexo B. 65 O segundo formulrio representado pela classe FormDetalhes, apresentando os detalhes da notcia escolhida. Ele composto por objetos da classe TextBox, da namespace System.Windows.Forms, que so utilizados para a apresentao de dados de texto. Este formulrio contm ainda, um objeto da classe PictureBox, da namespace System.Windows.Forms, utilizado para a apresentao da imagem referente notcia escolhida. A tela do emulador apresentando este formulrio apresentada na figura 41.
Figura 41: Tela do emulador exibindo os detalhes de uma notcia
Quando um usurio clica sobre o ttulo de uma notcia, no formulrio principal, invocado o mtodo da classe FormDetalhes, setNoticia, responsvel por carregar os detalhes da notcia escolhida, atravs do uso do WebMethod NoticiaPorID. Este mtodo apresentado na figura 42.
1 public void setNoticia(string id_noticia) { 2 NoticiaDetalhe noticia = wsNoticias.NoticiaPorID(id_noticia); 3 If(noticia != null) { 4 lbTitulo.Text = noticia.titulo; 5 tbResumo.Text = noticia.resumo; 6 tbTextoPlano.Text = noticia.texto_plano; 7 byte[] image = noticia.img_big; 8 System.IO.MemoryStream memStream = new System.IO.MemoryStream(image); 66 System.IO.MemoryStream(image); 9 If (memStream.Length != 0) { 10 try { 11 Bitmap bm = new Bitmap(memStream); 12 pbImagem.Image = bm; 13 } 14 catch(Exception) { 15 MessageBox.Show("Ocorreram problemas com o formato da imagem.", "Erro"); 16 } 17 } 18 else { 19 MessageBox.Show("No foi possvel apresentar a imagem","Alerta"); 20 } 21 } 22 } Figura 42: Mtodo setNoticia, da classe FormDetalhes
A segunda linha apresenta a execuo do WebMethod NoticiaPorID, que passa o valor do campo id_noticia recebido pelo mtodo setNoticia, da classe FormDetalhes. O resultado desta execuo armazenado em um objeto noticia, da classe NoticiaDetalhe. Em seguida, se este objeto no for nulo, as linhas de 4 a 6 atribuem aos objetos de texto, os valores de texto plano do objeto noticia. Na stima linha, atribudo a um array de bytes, os dados referentes imagem que representa a notcia em questo. Para que possa realmente ser apresentado como imagem, necessrio o procedimento localizado entre as linhas 8 e 20. O array de bytes transformado em um objeto memStream, da classe MemoryStream, contido pela namespace System.IO. Caso o tamanho do objeto memStream no seja vazio, ele convertido para um objeto da classe Bitmap, para ser, logo em seguida, atribudo ao objeto que ir apresentar a imagem no formulrio. Caso contrrio, exibida uma mensagem informando que no foi possvel apresentar a imagem. Aps ter sido apresentada a arquitetura desenvolvida, bem como o embasamento terico para sua realizao, o prximo captulo apresentar algumas concluses e consideraes obtidos a partir do trabalho.
67
5 CONSIDERAES FINAIS
A realizao deste trabalho permitiu demonstrar as principais caractersticas de tecnologias que esto comeando a ser utilizadas em larga escala: Web Services e dispositivos mveis. Ainda mais importante que apenas demonstrar seus usos, foi combin-los, visto que a aplicao desenvolvida apia-se em um modelo que permite seu funcionamento. Ou seja, alm da aplicao desenvolvida ser realmente utilizvel, ela utilizou-se de um modelo que pode ser facilmente modificado a fim de produzir aplicaes com outras finalidades. Isto pode ser afirmado pelo fato desta aplicao ser composta de trs componentes bsicos para solues desta natureza, que, neste caso, encontram-se em lugares diferentes em uma rede: banco de dados, Web Service, e aplicao final. Assim, pode-se dizer que a concretizao de conceitos encontrados separadamente na literatura permitiu a verificao da viabilidade da utilizao de Web Services, de aplicaes para PDAs que utilizam a plataforma operacional Pocket PC, quanto de ambos interagindo entre si. Alguns itens importantes para esta concluso so facilidade de implementao e desempenho. O desenvolvimento do cdigo de Web Services no apresenta grandes dificuldades, sendo bastante semelhante ao desenvolvimento de classes tradicionais. Sobre o desempenho de seu funcionamento, pode-se dizer que no seja o mesmo de comunicaes entre uma aplicao e um banco de dados, j que os dados trocados so baseados em XML, sendo necessrio um processo de parsing dos dados. Sobre a implementao de aplicativos para PDAs, ela pode ser considerada simples, j que a plataforma .NET Compact , na verdade, um subconjunto da plataforma .NET, alm de que ferramentas como Visual Studio .NET 2003 simplificam sua construo. Quanto questo de desempenho, necessrio um cuidado na construo destes aplicativos, dada a escassez de recursos dos dispositivos mveis. 68 A questo de comunicao em redes sem fio dos dispositivos mveis, no foi abordada neste trabalho, visto que o trabalho foi focado principalmente no desenvolvimento das aplicaes. Tendo este trabalho apresentado as principais caractersticas das tecnologias de Web Services e de aplicativos mveis, ambos trabalhando sob a plataforma .NET, possveis trabalhos futuros podem basear-se na construo de Web Services de diferentes plataformas para serem acessados a partir de aplicaes mveis construdas em vrias plataformas. Desta forma, tem-se um exemplo prtico de uma das principais caractersticas da teoria de Web Services: a interoperabilidade entre plataformas diferentes. Alm disto, outros domnios poderiam ser atendidos em trabalhos futuros, tal como Web Services para insero de informaes provenientes de outros tipos de dispositivos (sensores, leitores de digitais), em servidores remotos, por exemplo. 69
REFERNCIAS BIBLIOGRFICAS
(AMUNDSEN, 2002) AMUNDSEN, Michael; LITWIN, Paul. ASP.NET para desenvolvedores de Web sites. Rio de Janeiro: Editora Cincia Moderna Ltda., 2002. (ANDERSON, 2001) ANDERSON, R. Et al. Professional XML. Rio de Janeiro: Cincia Moderna LTDA., 2001. (BALLINGER, 2003) BALLINGER, Keith. .NET Web Services: Architecture and Implementation. Boston: Addison-Wesley, 2003. (JORGENSEN, 2002) JORGENSEN, David. Developing .Net Web Services with XML. Rockland: Syngress Publishing, Inc., 2002. (MSDN, 2003B) SOAP Especification Index Page. MSDN Library. Disponvel em <http://msdn.microsoft.com/library/default.asp?url=/library /en-us/dnsoapspec/html/soapspecindex.asp>. Acesso em: 15/11/2003. (MSDN, 2003D) Introducing XML Serialization. MSDN Library. Disponvel em <http://msdn.microsoft.com/library/default.asp?url=/library/en- us/cpguide/html/cpconintroducingxmlserialization.asp>. Acesso em: 15/11/2003. (MSDN, 2003E) WSDL Specification Index Page. MSDN Library. Disponvel em <http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/dnwsdl/html/wsdlspecindex.asp>. Acesso em: 23/11/2003. (MSDN, 2003G) .NET Compact Framework Overview. MSDN Library. Disponvel em <http://msdn.microsoft.com/vstudio/device/ compactfx.aspx>. Acesso em: 29/11/2003. 70 (NAMES, 2003) Namespaces in XML 1.1. World Wide Web Consortium, nov. 2003. Disponvel em <http://www.w3.org/TR/xml-names11/>. Acesso em 15/11/2003. (PAYNE, 2001) PAYNE, Chris. Aprenda em 21 dias ASP.NET. Rio de Janeiro: Campus, 2001. (PINTO, 2003) PINTO, Marcus Barbosa; SACCOL, Deise de Brum. Um estudo sobre esquemas para documentos XML. In: V Encontro de Estudantes de Informtica do Tocantins. Palmas: ANAIS ENCOINFO/EIN, 2003. p. 211 220. (SIDDIQUI, 2001) SIDDIQUI, Bilal. Deploying Web Services with WSDL: Part 1. IBM developerWorks, nov. 2001. Disponvel em <http://www- 106.ibm.com/developerworks/library/ws-intwsdl/>. Acesso em: 23/11/2003. (SOAP, 2000) SimpleObject Acces Protocol (SOAP) 1.1. World Wide Web Consortium, maio 2000. Disponvel em <http://www.w3.org/TR/ SOAP/>. Acesso em 15/11/2003. (SOAP, 2003) SOAP Version 1.2 Part 0: Primer. World Wide Web Consortium, jun. 2003. Disponvel em <http://www.w3.org/TR/ 2003/REC-soap12-part0-20030624/>. Acesso em 15/11/2003. (SOARES, 1995) SOARES, Luiz Fernando Gomes. Redes de computadores: das LANs, MANs e WANs s redes ATM. Rio de Janeiro: Campus, 1995. (TECHNET, 2003) Mobile Enterprise Solutions: What Is the Appropriate Pocket-Size Platform?. Microsoft TechNet. Disponvel em <http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/itsolutions/mobile/evaluate/mobilwhy.asp?frame=true>. Acesso em 29/11/2003. (UDDI, 2002) UDDI Programmer's API 1.0. UDDI.org, jun. 2002. Disponvel em <http://uddi.org/pubs/ProgrammersAPI-V1.01-Published- 20020628.pdf>. Acesso em 26/11/2003. 71 (UDDI, 2003) UDDI.org. UDDI.org. Disponvel em <http://www.uddi.org>. Acesso em 26/11/2003. (WSA, 2003) Web Services Architecture. World Wide Web Consortium, ago. 2003. Disponvel em <http://www.w3.org/TR/2003/WD-ws-arch- 20030808/>. Acesso em 09/11/2003. (WSDL, 2001) Web Services Description Language (WSDL) Version 1.1. World Wide Web Consortium, mar. 2001. Disponvel em <http://www.w3.org/TR/wsdl>. Acesso em 15/11/2003. (WSDL, 2003) Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. World Wide Web Consortium, nov. 2003. Disponvel em <http://www.w3.org/TR/wsdl20/>. Acesso em 15/11/2003. (XML, 2003) Extensible Markup Language (XML). World Wide Web Consortium. Disponvel em <http://www.w3.org/XML/>. Acesso em 10/04/2003. (XSD, 2001A) XML Schema Part 0: Primer. World Wide Web Consortium, maio 2001. Disponvel em <http://www.w3.org/TR/xmlschema- 0/>. Acesso em 15/11/2003. (XSD, 2001B) XML Schema Part 2: Datatypes. World Wide Web Consortium, maio 2001. Disponvel em <http://www.w3.org/TR/ xmlschema-2/>. Acesso em 15/11/2003.
using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Data.SqlClient; using System.Diagnostics; using System.Web; using System.Web.Services; using System.Web.Services.Protocols; using System.Xml.Serialization;
[WebService(Namespace="http://nds03/tcc")] [SoapInclude(typeof(Noticia))] [XmlInclude(typeof(Noticia))] /// <summary> /// Web Service para acesso a notcias do Portal CEULP/ULBRA. /// </summary> public class Noticias : System.Web.Services.WebService {
public ArrayList lista { get { return _lista; } set { _lista = value; } }
public DateTime dt { get { return _dt; } set { _dt = value; } }
public Banco banco { get { return _banco; } set { _banco = value; } }
public Noticia noticia { 74 get { return _noticia; } set { _noticia = value; } }
public SqlDataReader reader { get { return _reader; } set { _reader = value; } }
[WebMethod(Description="Retorna a lista de notcias dos cursos")] [SoapRpcMethod] public ArrayList NoticiasDosCursos(){ lista = new ArrayList(); dt = DateTime.Now; banco = new Banco(); reader = banco.selectSQL("SELECT n.id_noticia, n.titulo, n.resumo, n.texto_plano, nim.img_big FROM tb_noticia_curso nc INNER JOIN tb_noticia n ON nc.id_noticia = n.id_noticia INNER JOIN tb_noticia_imagem nim ON n.id_noticia = nim.id_noticia WHERE (n.data_inicial <= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') AND (n.data_final >= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') ORDER BY n.id_noticia DESC"); banco.fecharConexao(); if(reader != null){ while(reader.Read()){ noticia = new Noticia(reader.GetInt32(0), reader["titulo"].ToString()); lista.Add(noticia); } } return lista; }
[WebMethod(Description="Retorna a lista de notcias da Pastoral")] [SoapRpcMethod] public ArrayList NoticiasDaPastoral(){ lista = new ArrayList(); dt = DateTime.Now; banco = new Banco(); reader = banco.selectSQL("SELECT n.id_noticia, n.titulo, n.resumo, n.texto_plano, nim.img_big FROM tb_noticia_pastoral np INNER JOIN tb_noticia n ON np.id_noticia = n.id_noticia INNER JOIN tb_noticia_imagem nim ON n.id_noticia = nim.id_noticia WHERE (n.data_inicial <= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') AND (n.data_final >= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') ORDER BY n.id_noticia DESC"); banco.fecharConexao(); if(reader != null){ while(reader.Read()){ noticia = new Noticia(reader.GetInt32(0), reader["titulo"].ToString()); 75 lista.Add(noticia); } } return lista; }
[WebMethod(Description="Retorna a lista de notcias da Instituio")] [SoapRpcMethod] public ArrayList NoticiasDaInstituicao(){ lista = new ArrayList(); dt = DateTime.Now; banco = new Banco(); reader = banco.selectSQL("SELECT n.id_noticia, n.titulo, n.resumo, n.texto_plano, nim.img_big FROM tb_noticia_instituicao ni INNER JOIN tb_noticia n ON ni.id_noticia = n.id_noticia INNER JOIN tb_noticia_imagem nim ON n.id_noticia = nim.id_noticia WHERE (n.data_inicial <= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') AND (n.data_final >= '" + dt.Month + "/" + dt.Day + "/" + dt.Year + "') ORDER BY n.id_noticia DESC"); banco.fecharConexao(); if(reader != null){ while(reader.Read()){ noticia = new Noticia(reader.GetInt32(0), reader["titulo"].ToString()); lista.Add(noticia); } } return lista; }
[WebMethod(Description="Retorna um objeto da Classe NoticiaDetalhe")] public NoticiaDetalhe NoticiaPorID(string id_noticia){ Banco banco = new Banco(); NoticiaDetalhe noticia = null; reader = banco.selectSQL("SELECT n.id_noticia, n.titulo, n.resumo, n.texto_plano, nim.img_big FROM tb_noticia n INNER JOIN tb_noticia_imagem nim ON n.id_noticia = nim.id_noticia WHERE n.id_noticia ='" + id_noticia +"'"); banco.fecharConexao(); if (reader!=null){ while(reader.Read()){ noticia = new NoticiaDetalhe(reader.GetInt32(0), reader["titulo"].ToString(), reader["resumo"].ToString(), reader["texto_plano"].ToString(), (byte[])reader["img_big"]); } return noticia; } else { return null; } } }
public class Noticia {
private int _id_noticia; private string _titulo;
76 public Noticia(){ }
public Noticia(int Id_noticia, string Titulo){ this._id_noticia=Id_noticia; this._titulo=Titulo; }
public int id_noticia { get { return _id_noticia; } set { _id_noticia = value; } } public string titulo { get { return _titulo; } set { _titulo = value; } } }
public int id_noticia { get { return _id_noticia; } set { _id_noticia = value; } } public string titulo { get { return _titulo; } set { 77 _titulo = value; } }
public string resumo { get { return _resumo; } set { _resumo = value; } }
public string texto_plano { get { return _texto_plano; } set { _texto_plano = value; } }
public byte[] img_big { get { return _img_big; } set { _img_big = value; } } }
public FormConsumer() { // // Required for Windows Form Designer support // InitializeComponent(); wsNoticias = new nds03.tcc.Noticias(); listaDeNoticias = new ArrayList(); preencherLV(1); lbTipo.Text = "Notcias da Instituio";
// // TODO: Add any constructor code after InitializeComponent call // } /// <summary> /// Clean up any resources being used. /// </summary> protected override void Dispose( bool disposing ) { base.Dispose( disposing ); } #region Windows Form Designer generated code /// <summary> 80 /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> private void InitializeComponent() { this.lv = new System.Windows.Forms.ListView(); this.columnHeader1 = new System.Windows.Forms.ColumnHeader(); this.columnHeader2 = new System.Windows.Forms.ColumnHeader(); this.columnHeader3 = new System.Windows.Forms.ColumnHeader(); this.mainMenu = new System.Windows.Forms.MainMenu(); this.mTipos = new System.Windows.Forms.MenuItem(); this.miInstituicao = new System.Windows.Forms.MenuItem(); this.miPastoral = new System.Windows.Forms.MenuItem(); this.miCursos = new System.Windows.Forms.MenuItem(); this.tbQdNoticias = new System.Windows.Forms.Label(); this.lbTipo = new System.Windows.Forms.Label(); this.toolBar1 = new System.Windows.Forms.ToolBar(); this.btAtualizar = new System.Windows.Forms.Button(); // // lv // this.lv.Columns.Add(this.columnHeader1); this.lv.Columns.Add(this.columnHeader2); this.lv.Columns.Add(this.columnHeader3); this.lv.FullRowSelect = true; this.lv.Location = new System.Drawing.Point(8, 40); this.lv.Size = new System.Drawing.Size(224, 192); this.lv.View = System.Windows.Forms.View.List; this.lv.GotFocus += new System.EventHandler(this.lv_GotFocus); // // columnHeader1 // this.columnHeader1.Text = "Noticia"; this.columnHeader1.Width = 222; // // columnHeader2 // this.columnHeader2.Text = "Resumo"; this.columnHeader2.Width = 0; // // columnHeader3 // this.columnHeader3.Text = "texto_plano"; this.columnHeader3.Width = 0; // // mainMenu // this.mainMenu.MenuItems.Add(this.mTipos); // // mTipos // this.mTipos.MenuItems.Add(this.miInstituicao); this.mTipos.MenuItems.Add(this.miPastoral); 81 this.mTipos.MenuItems.Add(this.miCursos); this.mTipos.Text = "Tipos"; // // miInstituicao // this.miInstituicao.Text = "Instituio"; this.miInstituicao.Click += new System.EventHandler(this.carregar); // // miPastoral // this.miPastoral.Text = "Pastoral"; this.miPastoral.Click += new System.EventHandler(this.carregar); // // miCursos // this.miCursos.Text = "Cursos"; this.miCursos.Click += new System.EventHandler(this.carregar); // // tbQdNoticias // this.tbQdNoticias.ForeColor = System.Drawing.SystemColors.ControlText; this.tbQdNoticias.Location = new System.Drawing.Point(8, 24); this.tbQdNoticias.Size = new System.Drawing.Size(112, 16); this.tbQdNoticias.Text = "Clique na manchete"; // // lbTipo // this.lbTipo.Font = new System.Drawing.Font("Microsoft Sans Serif", 9F, System.Drawing.FontStyle.Bold); this.lbTipo.ForeColor = System.Drawing.Color.MidnightBlue; this.lbTipo.Location = new System.Drawing.Point(8, 4); this.lbTipo.Size = new System.Drawing.Size(160, 20); this.lbTipo.Text = "Notcias"; // // btAtualizar // this.btAtualizar.Location = new System.Drawing.Point(84, 240); this.btAtualizar.Text = "Atualizar"; this.btAtualizar.Click += new System.EventHandler(this.atualizar); // // FormConsumer // this.BackColor = System.Drawing.Color.WhiteSmoke; this.Controls.Add(this.btAtualizar); this.Controls.Add(this.lbTipo); this.Controls.Add(this.tbQdNoticias); this.Controls.Add(this.lv); this.Controls.Add(this.toolBar1); this.Menu = this.mainMenu; this.Text = "CEULP Notcias";
} #endregion 82
/// <summary> /// The main entry point for the application. /// </summary>
byte[] image = noticia.img_big; System.IO.MemoryStream memStream = new System.IO.MemoryStream(image); if (memStream.Length != 0) { try { Bitmap bm = new Bitmap(memStream); pbImagem.Image = bm; } catch(Exception) 85 { MessageBox.Show("Ocorreram problemas com o formato da imagem.", "Erro"); } } else { MessageBox.Show("No foi possvel apresentar a imagem","Alerta"); } } }
#region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> private void InitializeComponent() { this.tbTextoPlano = new System.Windows.Forms.TextBox(); this.lbTitulo = new System.Windows.Forms.Label(); this.pbImagem = new System.Windows.Forms.PictureBox(); this.tbResumo = new System.Windows.Forms.TextBox(); // // tbTextoPlano // this.tbTextoPlano.BackColor = System.Drawing.SystemColors.ActiveCaptionText; this.tbTextoPlano.Location = new System.Drawing.Point(8, 144); this.tbTextoPlano.Multiline = true; this.tbTextoPlano.ScrollBars = System.Windows.Forms.ScrollBars.Vertical; this.tbTextoPlano.Size = new System.Drawing.Size(224, 144); this.tbTextoPlano.Text = ""; // // lbTitulo // this.lbTitulo.Font = new System.Drawing.Font("Microsoft Sans Serif", 8F, System.Drawing.FontStyle.Bold); this.lbTitulo.ForeColor = System.Drawing.Color.MidnightBlue; this.lbTitulo.Location = new System.Drawing.Point(8, 0); this.lbTitulo.Size = new System.Drawing.Size(224, 40); this.lbTitulo.TextAlign = System.Drawing.ContentAlignment.TopCenter; // // pbImagem // this.pbImagem.Location = new System.Drawing.Point(136, 56); this.pbImagem.Size = new System.Drawing.Size(100, 72); this.pbImagem.SizeMode = System.Windows.Forms.PictureBoxSizeMode.StretchImage; // // tbResumo // 86 this.tbResumo.Font = new System.Drawing.Font("Microsoft Sans Serif", 7.25F, System.Drawing.FontStyle.Regular); this.tbResumo.Location = new System.Drawing.Point(8, 48); this.tbResumo.Multiline = true; this.tbResumo.ScrollBars = System.Windows.Forms.ScrollBars.Vertical; this.tbResumo.Size = new System.Drawing.Size(120, 88); this.tbResumo.Text = ""; // // FormDetalhes // this.Controls.Add(this.tbResumo); this.Controls.Add(this.pbImagem); this.Controls.Add(this.lbTitulo); this.Controls.Add(this.tbTextoPlano); this.Text = "FormDetalhes";
} #endregion } } 87
ANEXO C Classe proxy gerada a partir do Web Service definido na figura 24 FormConsumer.cs e FormDetalhes.cs
88
//----------------------------------------------------------------------- // <autogenerated> // This code was generated by a tool. // Runtime Version: 1.1.4322.573 // // Changes to this file may cause incorrect behavior and will be lost // if the code is regenerated. // </autogenerated> //-----------------------------------------------------------------------
// // This source code was auto-generated by wsdl, Version=1.1.4322.573. // using System.Diagnostics; using System.Xml.Serialization; using System; using System.Web.Services.Protocols; using System.ComponentModel; using System.Web.Services;
/// <remarks/> [System.Diagnostics.DebuggerStepThroughAttribute()] [System.ComponentModel.DesignerCategoryAttribute("code")] [System.Web.Services.WebServiceBindingAttribute(Name="SomaSoap", Namespace="http://nds03/michael")] public class Soma : System.Web.Services.Protocols.SoapHttpClientProtocol {
/// <remarks/> public Soma() { this.Url = "http://nds03/tcc/soma.asmx"; }