CHAPTER 5. DATA PRESENTATION AND ANALYSIS
5.6. Effect of ELOI on Educational Transformation
Um serviço Web é um componente de software acessível a outros componentes de software por meio de protocolos da Web. Serviços Web utilizam protocolos e linguagens de descrição de
interfaces baseadas em XML (Bray et al., 1998). O principal protocolo utilizado por serviços Web é o já mencionado Simple Object Access Protocol (SOAP). Esse protocolo serve para
empacotar e transmitir as mensagens trocadas em estruturas chamadas envelope SOAP. Esses
envelopes têm a função de descrever meta-dados das mensagens, por exemplo, endereço de entrega e padrões de codificação. Para transmitir os envelopes SOAP, as implementações de serviços Web utilizam protocolos de aplicação da Web, principalmente o HTTP. Esses pro- tocolos funcionam como protocolos de transporte para serviços Web, estabelecendo conexões fim a fim entre serviços e clientes.
As mensagens que trafegam entre serviços Web e clientes são representadas utilizando as regras especificadas nas interfaces dos serviços. Geralmente essas mensagens são geradas pelas aplicações comunicantes. Em geral, elementos dessas linguagens, por exemplo, métodos, são serializados e desserializados. Isto é, para o envio de uma mensagem a um serviço Web, elementos no formato da aplicação local são transformados para o padrão XML descrito na interface do serviço. Similarmente objetos de retorno de operações do serviço chegam ao cliente no formato XML e são transformados para o formato da aplicação local.
Um dos principais objetivos da Computação Orientada a Serviços é o estabelecimento de uma ampla rede de serviços interconectados com seus potenciais clientes permitindo o estabelecimento dinâmico de colaborações ad hoc entre sistemas de software. A Arquitetura Orientada a Serviços (SOA) (Papazoglou e Yang, 2002; W3C, 2002) foi concebida visando a esse objetivo. A Figura 2.9 mostra os componentes dessa arquitetura e suas inter-relações.
Provedor de Serviços Cliente de Serviços Registro de Serviços Registro Descoberta, Localização Ligação, Invocação
Figura 2.9: Arquitetura Orientada a Serviços (W3C, 2002).
Nesta arquitetura previu-se as seguintes atividades (W3C, 2002): registro, descoberta, loca- lização, ligação e invocação de serviços. O registro de um serviço é a inserção de meta-dados desse serviço em um componente de software acessível e conhecido por potenciais clientes desse serviço. Esse componente é denominado Registro de Serviços e pode, ele mesmo, ser um serviço. A descoberta e localização se dá por meio de uma pesquisa na qual o cliente procura por serviços que atendam a algum critério. Ao descobrir o serviço desejado, o cliente deve localizá-lo. Essas operações são feitas sobre os meta-dados contidos em Registros de Serviços. Com a localização do serviço desejado, o cliente pode executar um preâmbulo da invocação do serviço denominado ligação (bind). A ligação visa estabelecer dinamicamente os elementos necessários para que o cliente possa invocar as operações disponibilizadas no serviço. Com o estabelecimento da ligação entre cliente e serviço, o serviço pode ser invocado pelo cliente, por meio de chamadas das operações disponibilizadas no serviço. Quando um cliente invoca uma operação em um serviço, essa operação é executada no contexto do provedor do serviço.
2.3.1.1 Exemplo de implementação de Integração de Processos utilizando Serviços Web
Continuaremos utilizando o exemplo do Pedido de Compra para ilustrarmos como serviços Web podem ser utilizados no desenvolvimento da solução de software para ISI. A Figura 2.10 apresenta uma visão geral da arquitetura de software, considerando o uso de Serviços Web, das aplicações envolvidas no Pedido de Compra.
As operações necessárias para a realização dos processos públicos são representadas interfa- ces. Essas interfaces são disponibilizadas fisicamente em servidores de aplicação com suporte para serviços Web, por exemplo, o Apache Tomcat junto com o Apache Axis (APACHE, 2006a).
Aplicação Cliente
Serviços (from Aplicação Cliente)
Aplicação Loja
Aplicação Fornecedor
Serviços (from Aplicação Loja)
Serviços (from Aplicação Fornecedor) SWCliente SWClientInterface ReceberRespostaDisponibilidade() ReceberNotificaçãoDeEnvio() SWLoja SWLojaInterface ReceberPedido() ReceberPagamentoCancelamento() ReceberConfirmaçãoDeEnvio() ReceberRespostaDisponibilidade() SWFornecedor SWFornecedorInterface ReceberVerificaçãoDeDisponibilidade() ReceberPagamentoCancelamento() ReceberFinalizaçãoDeTransação()
Figura 2.10: Visão Geral da Arquitetura de ISI para realização do Pedido de Compra utili- zando Serviços Web.
As características de um serviço Web, tais como, suas operações, método de codificação e objetos complexos utilizados como parâmetros das operações, são descritos por meio de uma linguagem de descrição de interfaces chamada Web Service Description Language (WSDL) (W3C, 2001). WSDL baseia-se em XML. A Figura 2.11 apresenta fragmentos de código WSDL. Inicialmente são apresentados dados do serviço descrito. O segundo trecho mostra
a definição do tipo complexo Order utilizado pelo serviço. O terceiro fragmento mostra a
definição da operação purchaseOrder disponibilizada pelo serviço.
Arquivos WSDL não são para o consumo humano. Em geral, as ferramentas de suporte a Serviços Web disponibilizam mecanismos para geração automática de descrições WSDL a partir de códigos de programas descritos em linguagens de programação como C, Java e C++. O trecho de WSDL apresentado no exemplo foi gerado automaticamente no provedor
<wsdl:definitions
targetNamespace="http://localhost:8080/axis/services/Supplier1"> <!-- WSDL created by Apache Axis version: 1.4 Built on Apr 22, 2006 (06:55:48 PDT) --> <wsdl:types>
<schema targetNamespace="http://entity.supplier1"> <import
namespace="http://localhost:8080/axis/services/Supplier1"/> <import namespace="urn:Supplier1"/> <import
namespace="http://schemas.xmlsoap.org/soap/encoding/"/> .. ..
<complexType name="Order"> <sequence>
<element name="amount" nillable="true" type="xsd:double"/> <element name="client" nillable="true" type="tns1:Client"/> <element name="good" nillable="true" type="tns1:Good"/> <element name="goodQuantity" nillable="true" type="xsd:int"/> <element name="orderNumber" nillable="true" type="xsd:int"/> </sequence> </complexType>
.. ..
<wsdl:operation name="purchaseOrder"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="purchaseOrderRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://services.supplier1" use="encoded"/> </wsdl:input>
Figura 2.11: Excerto de um Arquivo WSDL.
do serviço pelo Apache Axis a partir de uma classe equivalente escrita na linguagem Java. Clientes de serviços Web também não precisam lidar diretamente com WSDL. Ambientes e pacotes de desenvolvimento de Serviços Web disponibilizam ferramentas para a geração de
stubs1 a partir de WSDL. Um stub é uma representação local do serviço remoto por meio
do qual a aplicação cliente consegue acesso indireto ao serviço. Geralmente espera-se que o stub seja gerado na linguagem de programação nativa do cliente. A Figura 2.12 mostra um fragmento de código de um stub em Java gerado a partir da descrição WSDL de um serviço. A utilização dos stubs por uma aplicação cliente estabelece uma organização arquitetural para a mesma. A Figura 2.13 ilustra esta arquitetura por meio de um diagrama de componen- tes da UML. Nesta arquitetura, serviços Web dependem de componentes que implementam a lógica de negócio da aplicação. Por outro lado, os componentes que implementam a lógica de negócios da aplicação utilizam os stubs para acessarem os serviços Web dos parceiros de negócio e realizarem colaborações.
Diversas características de Serviços Web tornam essa tecnologia apropriada para o de- senvolvimento de soluções de software para ISI. Curbera et al. (2001) enumeram as seguintes características fundamentais de serviços Web:
1Por falta de uma tradução para o Português amplamente aceita para o termo stub, manteremos o termo
public java.lang.Integer purchaseOrder(teste.integration.supplier1.Order order) throws java.rmi.RemoteException {
if (super.cachedEndpoint == null) {
throw new org.apache.axis.NoEndPointException(); }
org.apache.axis.client.Call _call = createCall(); _call.setOperation(_operations[7]); _call.setUseSOAPAction(true); _call.setSOAPActionURI(""); _call.setSOAPVersion(org.apache.axis.soap.SOAPConstants.SOAP11_CONSTANTS); _call.setOperationName(new javax.xml.namespace.QName("http://services.supplier1", "purchaseOrder")); setRequestHeaders(_call); setAttachments(_call);
try { java.lang.Object _resp = _call.invoke(new java.lang.Object[] {order});
if (_resp instanceof java.rmi.RemoteException) { throw (java.rmi.RemoteException)_resp; }
else {
extractAttachments(_call); try {
return (java.lang.Integer) _resp; } catch (java.lang.Exception _exception) {
return (java.lang.Integer)
org.apache.axis.utils.JavaUtils.convert(_resp, java.lang.Integer.class); }
}
} catch (org.apache.axis.AxisFault axisFaultException) { throw axisFaultException;
} }
Figura 2.12: Fragmento de um stub Gerado a partir de WSDL.
1. Interoperabilidade no nível de troca de informação. O nível mais básico de integração entre aplicações utilizando Serviços Web envolve a habilidade de trocar dados XML, por meio de um protocolo simples e padronizado, tal como o protocolo SOAP, que possa ser conduzido sobre os principais protocolos de comunicação da Web. Dessa forma, Serviços Web garantem um nível básico de interoperabilidade entre aplicações. 2. Representação uniforme de sistemas heterogêneos. As interfaces desses servi-
ços são descritas utilizando WSDL. As funcionalidades das aplicações são descritas em termos de Mensagens XML que podem ser trocadas entre as aplicações. O uso de re- presentações baseadas em XML provê independência de plataforma. Em adição, para o suporte a diferentes implementações com mesma funcionalidade, as interfaces de serviços Web estabelecem uma descrição funcional abstrata separada de possíveis implementa- ções diferentes.
3. Integração dinâmica de aplicações. A especificação do conjunto de serviços com os quais um cliente de serviços irá interagir pode ser definida em tempo de execução. Dessa forma, é possível estabelecer a integração entre aplicações em tempo de execução
Aplicação
Cliente Aplicação Loja Aplicação Fornecedor
Serviço Web Cliente Serviço Web Fornecedor Serviço Web Loja StubCLoja StubLCliente StubLFornec edor StubFLoja StubFCliente
Figura 2.13: Arquitetura da ISI para Realização do Pedido de Compra com a Utilização de stubs.
e, como conseqüência, a integração entre aplicações pode se dar dinamicamente. A integração em tempo de execução requer, tipicamente, mecanismos de ligação tardia e a existência de registros de serviços por meio dos quais as aplicações possam selecionar esses serviços baseando-se tanto em aspectos funcionais e não funcionais da integração; 4. Modelo de desenvolvimento da integração baseado em componentes. O mo- delo de comunicação de Serviços Web baseia-se em mensagens. Entretanto, o uso de interfaces bem definidas e padronizadas para envio dessas mensagens (operações) per- mite que serviços Web sejam tratados como componentes de software e a adoção do modelo de desenvolvimento baseado em componentes (Szyperski, 2002). Neste modelo, serviços podem ser considerados como componentes cuja interface é composta de um conjunto de operações abstratas descritas em seus documentos WSDL.
2.3.1.2 Evolução de ferramentas de suporte a Serviços Web
Atualmente é possível identificar três gerações de ferramentas de auxílio ao desenvolvimento de Serviços Web. Apesar de terem sido concebidas em um espaço relativamente curto de tempo, existem grande diferenças entre essas gerações.
A primeira geração de ferramentas não tentava abranger a utilização comercial de Serviços Web. O motivo principal para a criação das ferramentas da primeira geração foi provar que o conceito de Serviços Web é válido. Sendo assim, tais ferramentas não abordaram vários aspectos importantes para a utilização de Serviços Web no mundo real, como desempenho e suporte a diferentes cenários de trocas de mensagens. Um representante da primeira geração é o Apache SOAP.
A segunda geração possibilitou a aplicação de Serviços Web em aplicações reais. Foi adi- cionado suporte a alguns cenários de troca de mensagens, como troca de mensagens síncronas e assíncronas com resposta rápida. Cenários envolvendo assincronismo com respostas demo- radas ou troca de mensagens de grandes tamanhos continuaram sem suporte completo. Um representante da segunda geração é o Apache Axis até a Versão 1.4.
A terceira geração busca possibilitar a abrangência maior de domínio. As principais ca- racterísticas dessa geração são o melhor desempenho, melhor suporte a operações assíncronas e facilidade para utilização de várias extensões da especificação de Serviços Web. As no-
vas extensões definem padrões para a implementação de Serviços Web que atendem a vários aspectos não suportados pela especificação de Serviços Web original. Um representante da terceira geração é o Apache Axis Versão 2.0.
Observamos algumas diferenças entre a segunda e terceira gerações. Destacamos essas diferenças considerando a arquitetura Axis 2 e Axis 1:
• O Axis 2 não suporta apenas interações do tipo pedido-resposta, como o Axis 1. A ar-
quitetura na qual o Axis 2 é baseado permite que qualquer padrão de troca de mensagens seja modelado.
• No Axis 2 a troca de mensagens assíncronas é suportada tanto na API quanto na camada
de transporte. O comportamento da camada de transporte pode ser configurado através da API para utilizar uma via (apenas ida) ou duas vias (ida e volta). Ao utilizar o transporte de duas vias é possível contornar limitações da camada de transporte, como por exemplo timeout’s que ocorrem ao se aguardar por longos períodos de tempo pela resposta de um pedido.
• O processamento de mensagens SOAP é realizado através da API StAX (Axis1 utiliza
a API SAX), utilizando menos memória e obtendo uma vantagem de desempenho sobre o Axis 1.
• A arquitetura do Axis 2 é altamente modularizada facilitando o suporte a extensões
das especificações de Serviços Web. Para adicionar suporte a uma nova extensão basta instalar um módulo que implementa o suporte à nova extensão.
• O modelo de implantação de serviços é baseado em pacotes de arquivos. Para reali-
zar a implantação de um serviço no Axis 2, basta copiar o pacote para a localização determinada na configuração que o serviço é automaticamente instalado e iniciado.
• O mapeamento de tipos de dados trocados foi remodelado. No modelo do Axis 2 cada
mensagem ou objeto do documento SOAP é representado localmente por um objeto.