Exercícios de fixação
Questão 1 - B
Justificativa: Apenas a seção CDATA permite elementos como sinal de maior e de menor, sem que estes sejam interpretados de alguma forma pelos parsers, o que permite, por exemplo, a inclusão de código-fonte em alguma linguagem dentro de um arquivo XML.
Questão 2 - D
Justificativa: São duas as formas de definir gramáticas: DTD e XSD. Quanto ao texto, este se refere ao DTD, pois o mesmo apresenta como características: – Sintaxe bastante simples, mas não no padrão do XML.
– Não permite o uso de namespaces.
– Não permite a definição de estruturas de dados complexas. Questão 3 - E
Justificativa: Devem ser utilizados namespaces sempre que duas ou mais gramáticas se cruzam dentro do mesmo arquivo XML. Entidades são utilizadas para caracteres especiais, e os demais são componentes estruturais comuns de qualquer XML.
Questão 4 - A
Justificativa: O código ASCII 65, assinalado pela entidade A corresponde ao caractere "A" (letra a maiúscula). Os demais estão corretos. Questão 5 - B
Justificativa: São duas as formas de definir gramáticas: DTD e XSD. Quanto ao texto, este se refere ao XSD, pois o mesmo apresenta como características: – Sintaxe mais complexa, dentro das regras do XML.
– Permite a definição de estruturas de dados complexas. Questão 6 - A
Justificativa: O comando que causa uma repetição para cada elemento do conjunto é o for-each. Com relação ao select, este determina o que será selecionado para o conjunto, enquanto os demais elementos (if, choose e when) servem para desvios condicionais.
Questão 7 - E
Justificativa: SVG (Scalable Vector Graphics) é utilizado para a construção de gráficos vetoriais em XML, sendo amplamente utilizado no HTML 5. Quanto aos demais:
- XMI (XML Metadata Interchange), utilizado para troca de informações de metadados entre ferramentas de modelagem UML (Unified Modeling Language).
- MathML, utilizado na representação de modelos matemáticos.
- SMIL (Synchronized Multimedia Integration Language), para a construção de apresentações multimídia interativas.
- CML (Chemical Markup Language), para a formulação de elementos químicos. Questão 8 - C
Justificativa: A tecnologia XSL-FO (XML Stylesheet Language - Formatting Objects), este destina-se à criação de documentos em formatos voltados para plataformas específicas, como arquivos PDF, por exemplo. Diferencia-se do XSLT padrão, pois este último faz transformações em modo texto. Quanto ao SVG, o MathML e o CML, estas são tecnologias XML para domínios específicos, sendo respectivamente: gráficos, matemática e química.
Questão 9 - B
Justificativa: Para definir o formato de saída é utilizado o comando output; value-of retorna o valor do nó selecionado; variable declara uma variável local; apply-template aplica um modelo ao elemento corrente e filhos do mesmo.
Quando utilizamos template estamos definindo o modelo que será aplicado (com apply-template) a determinado tipo de nó for encontrado em um conjunto selecionado.
Questão 10 - E
Justificativa: O nó raiz da árvore de objetos de formatação deve ser um fo:root. Os filhos possíveis do fo:root são um único fo:layout-master-set, opcionalmente fo:declarations e fo:bookmark-tree, e uma seqüência de um ou mais elementos fo:page-sequence-wrapper e fo:page-sequence. Enquanto fo:layout-master-set define a geometria e sequenciamento das páginas; os filhos do fo:page- sequence, que são chamados de fluxos (contidos em fo:flow e fo:static- content), fornecem o conteúdo que é distribuído nas páginas.
Introdução
Com a popularização da Internet e aumento do comércio eletrônico, torna-se comum a necessidade de integração entre sistemas de diferentes plataformas, muitas vezes visando às transações financeiras e à logística.
Nesse novo cenário, o uso de XML em plataformas de serviços estilo RPC, inicialmente utilizando soluções XML-RPC e posteriormente Web Services, apresenta-se como uma grande solução de integração, garantindo a interoperabilidade com acoplamento extremamente baixo.
Com esse tipo de solução, novos horizontes se abriram, e sistemas voltados para o comércio entre empresas passaram a definir o conceito de B2B, posteriormente sendo expandido para o comércio direto com o consumidor, denominado B2C.
Objetivo:
1. Compreender o XML-RPC e o SOAP;
Conteúdo
XML-RPC
Uma solução simples para a criação de aplicativos distribuídos interoperáveis é o uso de XML-RPC, opção de arquitetura na qual as chamadas e respostas RPC seguem o formato XML para os dados de envio e recepção. Características do XML-RPC:
Criado para ser tão simples quanto possível, definindo as interfaces de
chamadas remotas, mas não implementando os métodos ouvintes nos servidores;
Utiliza um vocabulário baseado em XML;
Tem uma quantidade limitada de comandos (tags) para descrever
funções, tipos de parâmetros e tipos de retorno;
Utiliza o protocolo HTTP para o transporte na Internet;
Voltado para a comunicação computador a computador, e não de
usuário a computador;
O uso do protocolo HTTP e sintaxe XML permite sua passagem livre por
firewalls;
Várias implementações de servidores e clientes XML-RPC podem ser
encontradas.
Um exemplo de chamada e resposta XML-RPC pode ser observado a seguir:
Entre os elementos da sintaxe XML-RPC encontram-se:
methodCall:
Chamada de um método remoto a partir do cliente.
mehodResponse:
Define a resposta enviada pelo servidor ao cliente.
methodName:
Nome do método chamado no servidor.
Params:
Setor de parâmetros da chamada ou resposta.
Param:
Define um parâmetro, devendo conter seu valor e tipo.
Os tipos aceitos no XML-RPC podem ser observados na seguinte tabela:
Além desses tipos, podem ser criadas estruturas mais complexas com o uso de struct, como no exemplo a seguir:
Cada elemento de struct deve conter nome e valor, onde o valor pode ser outro struct, aplicado de forma recursiva.
Também podem ser criadas coleções com o uso de array, podendo ter como elementos dessas coleções elementos struct, os quais podem também utilizar array nos seus valores (value).
Logo, a combinação de estruturas complexas e coleções (ou vetores), de forma dinâmica e recursiva, permite expressar tipos de dados diversos com grande facilidade, o que viabiliza a implementação de clientes e servidores nas mais diversas plataformas.
É importante observar também que a chamada dos procedimentos está sujeita a falhas, e uma resposta indicando que algo errado ocorreu utilizará o elemento fault. Esse elemento pode ser definido como uma estrutura composta do código do erro (faultCode) e mensagem do erro (faultString).
Implementação em Java
Em termos de Java, uma biblioteca muito interessante para trabalhar com XML- RPC é disponibilizada pelo Apache, sendo seu uso baseado no mapeamento de um simples Servlet, um arquivo de propriedades e uma classe de negócios bem independente.
Com esses poucos componentes é criada a parte servidora do XML-RPC, sendo o cliente tão simples quanto, como pode ser observado a seguir.
SOAP
Em termos gerais, o SOAP (Simple Object Access Protocol) define um protocolo de comunicação remota estilo RPC com uso de XML, extensível e amplamente utilizado na comunicação com Web Services. Suas características principais são: 1: Objetivar a comunicação entre aplicativos;
2: Definir um formato padrão para envio de mensagens;
3: Permitir a comunicação na Internet de forma transparente aos firewalls; 4: Ser independente de plataforma e de linguagem de programação; 5: Utilizar sintaxe XML, bastante simples e extensível;
6: É uma recomendação da W3C desde o dia 24 de junho de 2003. A sintaxe do SOAP segue algumas regras importantes:
• A mensagem é criada com uso da sintaxe XML;
• Não pode ser utilizado um DTD;
• Não são permitidas instruções de processamento XML. O esqueleto de uma mensagem SOAP é apresentado a seguir:
A seção Header é opcional e permite a inclusão de informações específicas do aplicativo, como autenticação e pagamento, por exemplo. Se essa seção estiver presente deverá constar como o primeiro elemento filho do envelope SOAP. A seção Header é opcional e permite a inclusão de informações específicas do aplicativo, como autenticação e pagamento, por exemplo. Se essa seção estiver presente deverá constar como o primeiro elemento filho do envelope SOAP. O elemento Body apresenta a mensagem em si, definindo chamada ou resposta de um serviço solicitado.
Os elementos filhos de Body devem ter o namespace qualificado, como no exemplo seguinte com a chamada e a resposta.
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope> <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope>
A seção Fault é opcional e serve para indicar mensagens de erro. Quando presente na mensagem, Fault deve se apresentar como um elemento filho de Body, e permite apenas uma ocorrência nessa mensagem.
Os subelementos de Fault são apresentados na tabela a seguir.
Subelemento Significado
<faultcode> Código do erro ocorrido
<faultstring> Mensagem do erro
<faultactor> Informações acerca do responsável pela falha
<detail> Engloba informações específicas do aplicativo referentes ao
Web Services
O conceito de serviços não é novidade em termos de programação, tratando de componentes independentes de software que podem ser acionados para realizar determinadas tarefas, permitindo através de seu conjunto realizar ações maiores segundo uma ordem de chamada definida pelo aplicativo solicitante. Em termos de Internet, os tipos de serviço mais difundidos são Web Services, os quais podem ser classificados em dois tipos distintos:
SOAP Web Services, os quais permitem grande interoperabilidade com o uso do protocolo SOAP.
RESTful Web Services, onde é utilizado REST (REpresentational State Transfer), e as mensagens podem utilizar sintaxe XML ou JSON (Java Script Object Notation).
A grande diferença funcional entre o SOAP e o REST é a de que, enquanto o SOAP foca as chamadas de métodos remotos, o REST trabalha com envio e recepção de objetos ou recursos.
Várias bibliotecas, como JQuery, apresentam maior facilidade em lidar com REST, já que uma característica deste é justamente a simplicidade da transferência de informações, sem o uso de grande formalismo, o que viabiliza que a resposta seja expressa diretamente em JSON, no entanto, o formalismo das mensagens SOAP permite sua utilização facilitada em grandes ferramentas corporativas.
SOAP Web Services
Além do protocolo SOAP, utilizado na comunicação entre aplicativos para Web Services desse tipo, será necessário também um descritor de serviços, o WSDL (Web Service Description Language).
É através desse WSDL que diversas IDEs, como Visual Studio e NetBeans, conseguem criar o cliente com as chamadas corretas, deixando o programador com a sensação de que está fazendo uma simples chamada local, e sem envolver nenhum esforço para o mesmo na criação dos stubs de comunicação. Um documento WSDL define os serviços como coleções de endpoints ou portas. Em WSDL, a definição abstrata de endpoints e mensagens é independente de sua implantação na rede ou das conversões do formato de dados. Isso permite a reutilização de definições abstratas: mensagens, que são descrições abstratas dos dados que estão sendo trocados, e os tipos de portas, que são coleções abstratas de operações.
As especificações do protocolo e formato de dados concretos para um tipo de porta em particular constitui um vinculativo reutilizável. Uma porta é definida através da associação de um endereço de rede com um vínculo reutilizável, e um conjunto de portas de definir um serviço. Feitas essas considerações, um documento WSDL usa os seguintes elementos na definição de serviços de rede:
Types - Um recipiente para definições de tipo de dados usando algum
tipo de gramática (como XSD).
Message - Uma definição abstrata do formato de dados da
comunicação.
Operation - Uma descrição abstrata de uma ação suportada pelo
serviço.
PortType - Um conjunto abstrato de operações apoiadas por um ou
mais endpoints.
Binding - Um protocolo concreto e especificação do formato de dados
para um tipo de porta (PortType) particular.
Port - Um endpoint simples, definido como uma combinação de um
binding e um endereço de rede.
UDDI
Opcionalmente, esses Web Services podem ser cadastrados em um sistema para catalogação de serviços denominado UDDI (Universal Discovery and Description Integration), o qual equivale, na prática, a um serviço de nomes e diretórios.
A principal função do UDDI é retornar a URL do WSDL de um determinado serviço, após uma busca feita nos próprios registros desse catálogo, tendo como perfis de pesquisa:
• White Pages, referindo-se à busca de serviços pelo nome; • Yellow Pages, tratando da busca por assunto;
• Green Pages, baseado em características ténicas.
Finalmente, é feita uma comparação no quadro seguinte entre as diversas tecnologias de processamento distribuídas comumente utilizadas no mercado em termos de protocolo, descritor de chamadas e serviço de nomes e diretórios.
Para os Web Services do tipo RESTful é utilizado um descritor de serviços denominado WADL (Web Application Description Language).
Em termos gerais, os RESTful Web Services não mantinham uma preocupação com relação ao registro, como o uso de UDDI para SOAP Web Services; no entanto, as versões atuais do UDDI já incorporam elementos de busca para serviços REST, e o jUDDI permite que os registros sejam adicionados com sintaxe JSON.
A interoperabilidade através de Web Services é garantida pelo uso de protocolos modo texto de larga aceitação, como SOAP, e a presença de descritores de serviço WSDL para facilitar a criação dos stubs, permitindo a plena integração entre diferentes tecnologias e alto nível de reuso dos serviços e acoplamento extremamente baixo.
Criação de SOAP Web Services em Java
A plataforma JEE5 trouxe grandes facilitadores, inclusive para a escrita de Web Services, pois ao contrário de diversos arquivos de configuração XML, hoje trabalhamos com simples código anotado.
As anotações utilizadas são:
@WebService – define a classe como um serviço na Web; @WebMethod – define um método para esse serviço;
@WebParam – utilizado para definir parâmetros de chamada de um determinado método do Web Service.
Baseado nessas anotações, o servidor (GlassFish, por exemplo) implementa toda a infraestrutura para disponibilização do serviço, além de gerar a WSDL do mesmo, bem como o XSD (XML Schema), se fazer necessário.
Criação de Cliente dotNet
Como exemplo de interoperabilidade, pode ser criado um cliente dotNet a partir da WSDL do Web Service.
A tela seguinte mostra a opção que deve ser utilizada na criação do código necessário para a comunicação de forma automatizada.
Após adicionar a referência ao serviço, este pode ser invocado de forma muito simples a partir do código na linguagem escolhida dentro da plataforma dotNet, como pode ser observado a seguir, com uso da linguagem C#.
É fácil observar, partindo desse exemplo, a grande facilidade com que as duas plataformas podem interagir via Web Services, demonstrando de forma simples como esse tipo de serviço garante a interoperabilidade.
Sistemas B2B e B2C
Atualmente, os termos B2B e B2C são amplamente utilizados no mercado, mas o que realmente representam?
B2B (Business to Business) é a sigla utilizada no comércio eletrônico para definir transações comerciais entre empresas. Em outras palavras, é um ambiente onde uma empresa comercializa seus produtos para outras empresas. A natureza dessa operação pode ser revenda, transformação ou consumo. B2C (Business to Consumer) é a sigla que define a transação comercial entre empresa e consumidor final através de uma plataforma de e-commerce. A natureza dessa operação tende a ser apenas de consumo.
Os Web Services representam um passo à frente para permitir a colaboração entre várias entidades na Web e na superação dos problemas de interoperabilidade que podem aparecer. Parceiros B2B podem se beneficiar ao permitir que as entidades de negócios exponham suas interfaces de modo simples e interoperável.
Sistemas de informação baseados em uma arquitetura orientada a serviços que são capazes de integrar diferentes funcionalidades e oferecer um modelo de componente virtual que abstrai da peculiaridade de implementações específicas parecem ser uma solução muito atraente.
O ambiente de execução de Web Services apoia B2B comum e cenários B2C, na qualidade de um sistema de informação que representa o ponto central de uma arquitetura de hub-and-spoke. Se dois parceiros desejam se comunicar, eles
simplesmente resumem suas funcionalidades via Web Services, não diretamente um para o outro.
É feita uma distinção clara entre a interface e a implementação de um serviço, o que permite o registro, descoberta, composição e execução sem o conhecimento da localização da sua aplicação e tecnologia de implementação. Além disso, essa distinção apoia a definição semântica de um serviço, mesmo quando a sua aplicação não é necessariamente baseada em tecnologia semântica, mas talvez em um sistema legado.
Em ambientes onde existe a necessidade de comunicação assíncrona entre empresas, como no modelo bancário, é também comum o uso de mensagerias interfaceando os sistemas de ambas as empresas via mensagens.
Atividade proposta
Com o uso do NetBeans e servidor GlassFish, implemente em Java um Web Service que efetue as quatro operações matemáticas básicas: soma, subtração, multiplicação e divisão.
Utilize a opção "Testar Web Service” disponível a partir do NetBeans com o uso deste servidor específico, e teste as funcionalidades do serviço criado.
Referências
Laurent, S. Johnston, J. Dumbill, E. Programming Web Services with XML- RPC. Editora O’Reilly, 2001.
Kidd, E. XML-RPC HOWTO, Source Builders. 2001.
http://www.tldp.org/HOWTO/pdf/XML-RPC-HOWTO.pdf Richardson, L. Ruby, S. RESTful Web Services. Editora O’Reilly, 2007. Englander, R. Java and SOAP. Editora O’Reilly, 2002.
Saudate, A. SOA aplicado: Integrando com web services e além. Editora Casa do Código, 2012.
Exercícios de fixação
Questão 1
Qual das opções abaixo NÃO é uma característica do XML-RPC?
a) Criado para ser tão simples quanto possível, definindo as interfaces de chamadas remotas, mas não implementando os métodos ouvintes nos servidores.
b) Utiliza um vocabulário baseado em JSON.
c) Tem uma quantidade limitada de comandos (tags) para descrever funções, tipos de parâmetros e tipos de retorno.
d) Utiliza o HTTP para o transporte na Internet.
e) Voltado para a comunicação computador a computador, e não de usuário a computador.
Questão 2
Em termos de XML-RPC, quando ocorre um erro no atendimento à solicitação, a mensagem referente a este erro será retornada em que elemento da resposta? a) params b) faultCode c) faultString d) param e) methodName Questão 3
Com relação à sintaxe do SOAP, qual das opções está INCORRETA? a) A mensagem é criada com uso de XML.
b) Precisa do namespace soap-envelop. c) Precisa do namespace soap-encoding. d) Pode ser utilizado um DTD.
Questão 4
"Para o SOAP a seção _________ é opcional, e permite a inclusão de informações específicas do aplicativo, como autenticação e pagamento, por exemplo. Se esta seção estiver presente deverá constar como o primeiro elemento filho do envelope."
Qual opção preenche corretamente a lacuna? a) Body b) Footer c) Fault d) Header e) Tail Questão 5
Considere as afirmativas abaixo, com relação ao SOAP: I - Objetiva a comunicação entre o servidor e o usuário final.
II – Permite a comunicação na Internet de forma transparente aos firewalls. III – Utiliza sintaxe JSON.
IV – É independente de plataforma e de linguagem de programação. Qual a opção que indica a quantidade de afirmativas corretas?
a) As quatro estão corretas. b) Apenas três estão corretas. c) Apenas duas estão corretas. d) Apenas uma está correta.
e) Nenhuma das afirmativas está correta. Questão 6
Para Web Services SOAP é utilizado um descritor de serviços denominado: a) WSDL
b) UDDI c) XML d) SOAP e) REST
Questão 7
Para definir um Web Service em linguagem Java através de anotações, a classe deve ser anotada com _________, cada método que precise ser exposto como serviço deve ser anotado com __________, e cada parâmetro presente em cada um desses métodos deve ser anotado com _________.
Qual opção preenche corretamente as lacunas? a) @Stateless, @EJB e @Servlet
b) @Stateless, @EJB e @MessageDriven
c) @WebParam, @WebMethod e @WebService d) @Override, @Remote e @Local
e) @WebService, @WebMethod e @WebParam Questão 8
Um componente de grande relevância nos ambientes de computação distribuída é o sistema de registro, normalmente um serviço de nomes e diretórios. Quais são, respectivamente, os sistemas de registro para RMI-IIOP, CORBA e Web Services?
a) RMI Registry, COS Naming e UDDI. b) JNDI, COS Naming e UDDI.
c) WSDL, UDDI e SOAP.
d) JNDI, COS Naming e WSDL.
e) WSDL, CORBA IDL e RMI Registry. Questão 9
Considerando-se os documentos WSDL, qual elemento é relacionado a "um conjunto abstrato de operações apoiados por um ou mais endpoints"?
a) Message b) Types c) Binding d) PortType e) Service
Questão 10
Qual o tipo de Web Service que trabalha com envio e recepção de objetos, e