Com o avanço da tecnologia e o crescente desenvolvimento de novos sistemas e plataformas, a necessidade de sistemas interconectados e a grande variedade de ferramentas de desenvolvimento surgem à necessidade de padronizações que solucionem os problemas de integração de software através da web.

Com base no item acima este trabalho tem o objetivo de descrever o conjunto de tecnologias que visam proporcionar o desenvolvimento de serviços na web. O estudo é feito a partir artigos e livros publicados e visa mostrar o desenvolvimento desta tecnologia nas principais linguagens atuais.

Palavras-Chave: Web Services, XML, WSDL, UDDI, Integração de dados.

1 introdução

Web Services é uma das mais recentes evoluções na maneira de desenvolver aplicações distribuídas, apesar de estar ainda em desenvolvimento e sua padronização em discussão esta tecnologia esta empolgando vários fabricantes e desenvolvedores de software.

Os Web Services são na verdade conjunto de técnicas e componentes de software que possibilitam a integração de dados entre sistemas heterogêneos. Em usa maioria são sistemas com baixo nível de acoplamento, distribuídos, que utilizam protocolos bem conhecidos para comunicação através da rede global de comunicação: A Internet.

1.1 A Evolução dos sistemas de software

Fazendo um retrocesso na evolução do desenvolvimento de software veremos que existe uma divisão histórica na produção de software.

1.1.1 Primeira Geração: Banco de Dados e Aplicações Cliente/Servidor

As primeiras aplicações construídas visando negócios foram os projetos baseados na arquitetura cliente servidor. A aplicação cliente, funcionando em um PC, executa chamadas a banco de dados usando uma linguagem de consulta como SQL.

Este modelo baseado em dois níveis de camada teve uma grande utilização nos anos meados dos anos 80. A padronização das arquiteturas de banco de dados permitiu a produção de sistemas em rede de baixo custo, também conhecidos como softwares de prateleira, onde a lógica do negócio fica separada do armazenamento das informações.

Os clientes possuem toda a lógica de apresentação e o banco de dados se encarrega de armazenar as informações através da rede. Estes clientes são popularmente conhecidos como “fat clients”.

1.1.2 Segunda Geração: Servidores de Aplicação Web

Apesar do desenvolvimento da Internet ter iniciado nos anos 60 seu uso só se espalhou a partir dos anos 80 nas universidades e agências governamentais dos Estados Unidos. Somente com a criação da World Wide Web foi possível à comunicação e a transação de negócios.

Esta arquitetura permitia aos browsers acessassem diretamente os bancos de dados através de interfaces tipo CGI (Common Gateway Interface) que normalmente faziam parte do servidor web. O advento da aplicação web provou ser mais útil quando o "cliente" estava geograficamente afastado que uma aplicação tradicional.

Como na arquitetura cliente/servidor esta geração trouxe avanços de desempenho, escalabilidade e flexibilidade para as aplicações. A alta demanda de processamento conduziu a um novo tipo de arquitetura para os servidores de aplicação.

Com as padronizações de componentes e servidores web foi possível à criação de uma arquitetura baseada em três camadas, separando os dados, as regras de negócios e a camada de apresentação. Esta arquitetura foi conhecida como arquitetura de três camadas e é baseada em componentes. A arquitetura baseada em componentes trouxe avanços consideráveis na produção de software sendo as características mais relevantes:

Especialização/Funcionalidades: É a habilidade de desenvolver "pedaços" do código dedicados às funções específicas, que executadas corretamente, podem de forma eficiente interagir com outros "pedaços" do código dedicado a outras funções.

Comunicações Padronizadas: Ao contrário das aplicações da primeira geração, as aplicações da segunda geração tiveram que se comunicar através de uma "nuvem" chamada Internet. Estes padrões ocorreram em diversos níveis incluindo protocolo de redes (TCP/IP, HTTP), apresentação (HTML), segurança (HTTPS, certificados digitais), lógica da aplicação (Java, Javascript, cgi), etc..

Execução Distribuída: os padrões da Internet permitiram as aplicações funcionarem em ambos os lados da "nuvem". Os pedaços da aplicação funcionam aonde fazem mais sentido. A lógica do negócio funciona no lado do servidor e a lógica da apresentação no lado do cliente.

Confiabilidade: o modelo das Máquinas Virtuais Java (JVM) forneceu o conceito conhecido como “caixas de areia” onde cada aplicação só interage e funciona em um espaço limitado não interferido ou acessando os componentes do sistema como um todo.

Portabilidade: outra vantagem é que os desenvolvedores projetaram seus sistemas com base nas máquinas virtuais podendo ser facilmente portadas para as mais diversas plataformas.

Internacionalização/Conectividade: ao contrario de linguagens como C e C++ a inclusão de linguagens como Java (código Unicode) assegurou o suporte para todos os tipos de linguagem incluindo linguagens multi-byte como o Japonês. O uso de API´s permitiu a conectividade facilitando a integração sem “emendas” com outras estruturas existentes.

1.1.3 Terceira Geração: Web Services

Os Web Services representam um novo modelo de arquitetura representando um grande avanço tecnológico. É a primeira arquitetura que propõem a comunicação por protocolos padrões como o HTTP e XML promovendo a evolução de serviços onde às lógicas do negócio são expostas através de regras de programação. Mesmo que muitos dos conceitos são derivados das arquiteturas anteriores à arquitetura orientada a serviços trouxe a quebra de um paradigma na construção de aplicações no nível de transparência e interoperabilidade.

1.2 Conhecendo os Web Services

Basicamente, Web Services são serviços distribuídos na WEB que processam mensagens SOAP codificadas em XML enviadas através do protocolo HTTP. Podemos observar que a Arquitetura de um Web Services (WSA) e formada por um conjunto de tecnologias que agregadas conseguem grandes resultados para os programadores WEB.

Web Services fornece uma interoperabilidade entre componentes de software independente da distância, infra-estrutura e local físico. O principal motivo do crescimento desta tecnologia é devido a sua Arquitetura Orientada a Serviços (SOA) que consiste em uma coleção de serviços autônomos identificados por URLs, com interfaces criadas através de WSDL e processamento de mensagens XML. A arquitetura orientada a serviços difere de sistemas orientados a objetos (OO) e sistemas procedurais no que diz respeito à ligação entre os componentes. Em geral sistemas OO e procedurais são conectados através de chamadas baseadas em tipos e nomes e em uma SOA a ligação consiste na troca de mensagens o que permite estabelecer restrições para o envio/recebimento de informações separando de forma clara a estrutura comportamental da estrutura de descrição.

Outra vantagem associada a essa tecnologia é a facilidade de implementação e flexibilidade de implantação em sistemas legados onde muitas vezes sua alteração é de difícil acesso.

Como vimos anteriormente um Web Services e uma aplicação de software que pode ser acessada remotamente através de diferentes linguagens e protocolos. Normalmente um Web Services e identificado através de urls como qualquer outra página WEB. Na maioria dos sistemas WEB a resposta a requisições na Internet é feita através de chamadas efetuadas por uma pessoa/browser, resultando no retorno de um conteúdo texto no formato HTML.

Figura 1.1: Interação tradicional entre browser e servidor web.

O acesso ao Web Service e semelhante na forma de acesso tradicional na internet, a diferença encontra-se no conteúdo que é enviado na requisição do cliente e o retorno do servidor. Os clientes de um Web Services enviam mensagens SOAP contendo chamadas a um método e parâmetros que por ventura sejam necessários. O servidor por sua vez interpreta esta chamada e retorna a informação XML resultante do processamento.

Por ser uma troca de dados em formato amigável pode ser transferida de um computador para outro não importando:

· O tipo ou modelo de computador e/ou sistema operacional usado.

· O lugar no mundo em que o servidor ou cliente se encontra.

· A linguagem que foi implementada o software cliente/servidor.

· A necessidade de o cliente conhecer as versões de protocolos e softwares estão sendo utilizadas no servidor.

Figura 1.2: Interação entre browser e um Web Service.

Os web services resolveram importantes questões de difícil solução na comunicação entre sistemas, porém nem tudo é perfeito. Existem varias questões ainda em aberto para que tenhamos uma solução completa. Segurança, suporte a transações ainda são questões polêmicas não previstas pelo protocolo SOAP.

Pode-se implementar Web Services através de componentes programados e baixados de grupos como o Apache Group ou através de fornecedores comerciais privados como Microsoft ou IBM.

A maioria dos fabricantes de software disponibilizam ferramentas que facilitam o desenvolvimento dos web services, mas isso não impede de se criar suas próprias implementações do serviço.

Em geral podem ser desenvolvidos por qualquer linguagem de programação baseadas em sockets.

A tecnologia Web Services traz também um importante avanço no desenvolvimento de software. Historicamente sabemos dos inúmeros problemas ocorridos devido à alta dependência causada pela utilização de sistemas de um determinado fornecedor de software. Em geral, softwares de uma determinada empresa só se comunicam entre softwares do mesmo fabricante e caso o cliente resolver optar pela troca do fornecedor por qualquer motivo que seja, praticamente teria de recomeçar do zero. As tecnologias dos Web Services forçam a quebra deste paradigma incrementando um ganho potencial para as empresas.

Para que existam padrões e assim possa existir também a flexibilização dos serviços o World Wide Web Consortium (W3C) controla e desenvolve especificações e padronizações para a arquitetura dos Web Services. Outra importante organização no mundo é a Organization for the Advancement of Structured Information Standards (OASIS) que abrange um consórcio mundial para o desenvolvimento de padrões para o comércio eletrônico.

1.3 As vantagens no uso de Web Services

Existem inúmeras vantagens no uso de sistemas baseados em Web Services, principalmente por proporcionar de forma simples e rápida oportunidades que seriam impossíveis de serem concretizadas devido à alta complexidade e custo em outras tecnologias equivalentes. O sucesso na rede de negócios vai depender de uma boa avaliação e estudo para a aplicação desta tecnologia. Nem tudo pode ser resolvido através de Web Services, mas em geral consegue-se:

· Integrar sistemas legados com baixo custo

· Diminuir custos operacionais

· Diminuir custo/tempo no desenvolvimento de sistemas

· Aproximar-se mais com seus clientes e parceiros comerciais

· Prospecção de novos mercados e negócios.

1.3.1 Integrando sistemas legados com baixo custo

Quando se fala em sistemas legados, estamos entrando em um terreno frágil, pois sistemas legados são sinônimos de confiança. Já foram gastos anos e anos de desenvolvimento e análise e dificilmente consegue-se convencer qualquer gerente de uma empresa a arriscar em novas tecnologias.

Não é preciso abandonar o seu sistema... A arquitetura dos Web Services vem para complementar com novas funcionalidades sistemas cujo raio de ação era restrito. Trabalhar com sistemas internos é menos arriscados do que sistemas externos, o treinamento em novas tecnologias pode ser um ponto forte de decisão entre fazer ou não. Muitos desenvolvedores ficam apavorados quando é solicitada a manutenção de sistemas antigos como COBOL, etc... Principalmente se for para integrar com os dados do novo parceiro ou cliente que está entrando no mercado. É interessante lembrar que muitas vezes, erroneamente, confundimos a ligação de sistemas antigos versus sistemas ruins. Só por que tecnologicamente está ultrapassado não simboliza que é um sistema ruim, muito pelo contrario, existem empresas que não trocariam em hipótese nenhuma seu sistema arcaico por qualquer outro sistema no mundo.

1.3.2 Diminuindo custos operacionais

Com a competitividade do mercado constantemente somos obrigados a diminuir custos operacionais para manter a saúde de nossa empresa. Existem varia maneias de reduzir o custo operacional usando Web Services. Nos dias de hoje é difícil imaginar uma interconexão entre computadores que seja mais barata que a Internet, assim todo computador conectado na WEB poderia ser cliente ou servir como prestador de serviços.

Podem-se economizar custos significativos através de serviços de Intercâmbio Eletrônico de Dados (EDI) com clientes e fornecedores e com o busca e envio de relatórios on-line dispensando a enorme quantidade de papeis impressos. Os custos podem diminuir ainda quando racionalizamos as tarefas do dia a dia. O avanço das tecnologias de redes sem fio (Wireless) e o desenvolvimento de dispositivos móveis (PDAs) pode-se melhorar sensivelmente os ganhos de produtividade. Receber as suas tarefas sem necessariamente estar no escritório, receber a lista de entregas e realocar as entrega de um caminhão que acabou de estragar são exemplos práticos de situações cotidianas de nossa vida.

1.3.3 Diminuindo custo/tempo no desenvolvimento de sistemas

Um dos mais importantes conceitos na área de desenvolvimento de software foi o conceito de reutilização de código. Cada vez mais os desenvolvedores procuram maneiras de abrandar o desenvolvimento de aplicações iniciadas do zero. Com a primeira leva de aplicações web muitos fabricantes acabaram sendo obrigados a reescrever suas aplicações para usufruir das vantagens de mobilidade. Com a evolução da tecnologia e o avanço da orientação a objetos, vários fabricantes adotaram tecnologias como CORBA, DCOM e outras para minimizar a reprogramação de aplicações distribuídas. Nesta mesma linha de raciocínio a arquitetura de sistemas orientados a serviços vem contribuir com a reutilização de sistemas legados propondo uma coexistência harmônica. Com esta coexistência diminuem-se drasticamente os custos de desenvolvimento e o tempo de integração entre sistemas distribuídos via WEB.

1.3.4 Aproximando-se de seus clientes e parceiros comerciais

Estar próximo de seus clientes com certeza e uma das chaves para o sucesso, principalmente se você e um prestador de serviços. Fazer com que seus clientes interajam com sistemas de pedidos, entregas, cobranças e acompanhamento de processos traz agilidade e praticidade sem falar na redução de custos já vistos anteriormente. Muitas empresas poderiam abrir acesso a seus sistemas de controle, sem se arriscar, permitindo que seus clientes tenham a liberdade de acessar as informações pertinentes ao seu negocio na hora que melhor lhe convir.

1.3.5 Prospectando novos mercados

A tecnologia de Web Services permitiu a criação de novos tipos de serviços e modalidades de comércios. Os negócios virtuais cresceram com força nestes últimos anos. Livrarias e agências de viagens são exemplos que demonstram claramente as possibilidades deste novo modelo de negócio. Em geral, nenhuma empresa tem condições suprir todas a necessidades de seus clientes de maneira satisfatória sem envolver uma grande estrutura. Você deseja viajar para o exterior e na maioria das vezes se depara com o problema de como planejar suas férias. Em qual companhia comprar as passagens aéreas, onde se hospedar, alugar um carro, comprar passeios turísticos no exterior? Existe hoje empresas que vendem todas estas soluções ao alcance de alguns cliques, satisfazendo e fidelizando seus clientes. Você poderia pensar, esta empresa deve ter uma mega estrutura para atendimento de seus clientes, mas contrariando esta idéia, muitas empresas estão sediadas em uma sala modesta com um número extremamente reduzido de funcionários.

Figura 1.4: Empresas pequenas e grandes negócios

1.4 As desvantagens e riscos dos Web Services

Embora visto as vantagens do uso de Web Services sabe-se que existem varias questões que ainda estão descobertas ou que possuem soluções que não atendem 100% das expectativas. È importante analisar cada caso para verificar se a tecnologia vai atender aos pré-requisitos de sua aplicação, Web Services não é a solução mágica que irá resolver todos os seus problemas.

Disponibilidade é umas das peças chaves para um ambiente WEB, mesmo que tudo em sua empresa esteja funcionando corretamente problemas nos links de Internet podem provocar perdas para o seu negócio.

Normalmente após algum tempo de uso destes serviços tanto como cliente ou fornecedor você notará que mudanças nas chamadas aos Web Services podem trazer transtornos. Evite alterar as chamas aos métodos já implantados, pois, dificilmente saberá quem está utilizando-o, e muito mais conseguir avisar sobre mudanças.

Utilizar Web Services para uso comercial pode ser uma idéia genial, porem muitas vezes nos deparamos com problemas de complexidade que extrapolam suas limitações. Como iremos ver mais detalhadamente o serviço funciona sobre o protocolo HTTP que por sua vez não é seguro. A única opção atualmente e agregar ao seu serviço o uso do SSL (Secure Socket Layer). O SSL protege com boa segurança o envio de informações, porem, torna as transações mais lentas sendo, muitas vezes, inadequado a grandes volumes de transferência de dados.

A falta de padrões também prejudica o desenvolvimento dos serviços, a autenticação, a comunicação de feedback dos resultados são itens que não estão padronizados e dependem das implementações de cada desenvolvedor.

Em determinados negócios a importância de se ter controle das transações e mecanismos de falha e recuperação são vitais. Neste ponto os Web Services deixam muito a desejar, não há garantias que determinadas transações serão completadas em dependência de outras. Ainda, mais se forem Web Services de prestadores diferentes.

Desempenho e uma questão que também deve ser observada, visto que todo serviço trafega através da Internet. A velocidade de transmissão na Internet é uma variável que não se pode controlar, ou seja, sistemas onde performance seja vital não são candidatos a adotarem esta tecnologia. Outro aspecto a ser considerado é o processamento envolvido, como os dados são trocados em formato XML, que não deixa de ser texto, consome uma quantidade considerável de processamento para a conversão dos dados. Se os dados forem complexos (principalmente dados binários como imagens) a codificação e decodificação destes dados podem levar tempo.

A formação de pessoal qualificado pode ser outro entrave devido ser uma tecnologia recente e em evolução. Não existem profissionais com larga experiência ou conhecimentos na área o que leva muitas vezes uma certa desconfiança e os poucos encontrados podem custar caro.

Como a produção de novos padrões e especificações estão em andamento podem ocorrer mudanças em suas aplicações tornando-as desatualizadas em curtos períodos de tempo.

Vários fabricantes ainda estão “brigando” pela imposição de seus padrões ou implementações para que estas sejam os padrões de mercado. Optar por um ou outro fabricante não indicará garantias que a escolha seja a melhor ou a mais aproximada aos padrões ditos corretos.

Todos estes aspectos não impedem de se utilizar à tecnologia, mas é importante ter ciência de que existem problemas e que devem ser tratados e considerados.

2 ARQuitetura orientada a serviços (soa)

Basicamente uma SOA é baseada em um modelo simples envolvendo três entidades:

Figura 2.1: Arquitetura básico de um Web Services

O Service Requester é a aplicação que solicita um serviço. A aplicação recorre através dos Service Registrys as informações referentes à localização do serviço. O Service Registry é uma aplicação que retorna as informações para uso de um serviço.

O Service Provider funciona de forma semelhante a um sistema de paginas amarelas, oferecendo os serviços para que possam ser encontrados de forma fácil.

Um bom exemplo para este cenário é um E-commerce de uma Livraria. A requisição é realizada através de um cliente. O cliente que pode ser um browser qualquer, solicita o preço de um determinado livro. O Web Services recebe e processa este pedido e retorna uma resposta contendo o preço do livro.

Web Services e consumidores de Web Services são geralmente associados a negócios do tipo B2B. Isto acontece quando a empresa que provê o serviço também é cliente de outro serviço. Os Web Services são projetados para suportar interação e interoperabilidade podendo ser, ou não, de arquiteturas diferentes.

Existem cinco itens básicos nesta arquitetura:

HTTP: Hipertext Transport Protocol usado para transportar as informações pela web

XML: Extensible Markup Language é utilizada na de definição e semântica dos dados.

SOAP: Simple Object Access Protocol é o formato de mensagens para chamada de métodos remotos.

WSDL: Web Services Description Language descreve as características oferecidas pelo serviço.

UDDI: Universal Discovery, Description and Integration descreve um tipo especial de registro que lista os Web Services na Internet.

2.1 Hipertext Transport Protocol (HTTP)

Controlado pela W3C o HTTP descrito na RFC 2616 é um dos principais protocolos de transporte na Internet, atuando na camada de aplicação, com objetivo de transportar as requisições realizadas entre os clientes e os servidores. A partir do SOAP 1.2 não é mais necessário a utilização do HTTP devido a criação de novos protocolos.

Outra especificação utilizada é o RFC 2965 que especifica como criar sessões (cookies) nas requisições e respostas de comunicação.

2.2 Extensible Markup Language (XML)

Um dos grandes desafios para a integração de sistemas computacionais distintos é a integração de dados, sendo que, por muitos anos a troca de informações foi baseada na troca de arquivos textos. É sabido que existem muitos problemas em se utilizar este modelo de comunicação devido ao custo de processamento, a rigidez de formatos, a falta de mecanismos de validação e consistência de dados.

Para ajudar a resolver este problema a W3C propôs uma representação de dados de formato simples e de fácil representação para o intercambio de dados sendo chamada de XML. A principal característica desta linguagem e o seu mecanismo de extensão que possibilita a definição de novas marcações pelo fato de serem criadas pelo próprio usuário. O uso do XML simplifica enormemente a tarefa de criar documentos para a troca de dados entre sistemas e sua especificação possui um conjunto de regras de sintaxe que determina o formato que as marcações devem seguir. O vocabulário de um documento XML e desenvolvido de acordo com a as marcações acordadas entre as partes que irão integrar o sistema e por ser em formato texto é praticamente acessível por qualquer sistema.

O XML basicamente é dividido em:

Documento XML	É um arquivo que obedece às normas XML, compreendendo toda a estrutura de informações necessárias sendo similar a um banco de dados.
Parser XML	É um programa que analisa o documento XML e reproduz os dados de uma maneira legível para o sistema. O Parser XML transforma os dados descritos no documento XML em estruturas eficazes para o processamento de dados.
Document Type Definition (DTD)	Descreve as marcações que podem ser utilizadas e seus relacionamentos com as demais marcações. A partir de 2001 este modelo vem sendo substituído pelo modelo de esquemas.
Esquema XML	Versão aperfeiçoada do DTD mantendo as mesmas características da anterior garantindo a validação das marcações de acordo com as regras definidas no esquema. A validação ocorre de forma externa ao sistema através do parser XML evitando a reprogramação toda vez que for desenvolvido um novo sistema.
Namespaces	Utilizado para evitar conflitos entre os nomes das marcações (tags). Criando um namespace para cada documento XML evitamos a conflitos entre nomes idênticos.

2.2.1 Estrutura Geral

Na linguagem XML existem dois componentes principais: os elementos e os atributos. Os elementos são estruturas que permitem a atribuição de dados simples, como seqüências de números e letras, ou elementos ditos complexos.

01 <?xml version=”1.0” encoding=”utf-8”?>

02 <lista>

03 <carro idcarro=”1”>

04 <modelo>Corsa Sedan</modelo>

05 <marca>GM</marca>

06 <ano>

07 <fabricacao>2004</fabricacao>

08 <modelo>2004</modelo>

09 </ano>

10 <opcionais>AC, DH, TE</opcionais>

11 <valor>22.500</valor>

12 </carro>

13 <carro idcarro=”2”>

14 <modelo>Gol Flex</modelo>

15 <marca>VW</marca>

16 <ano>

17 <fabricacao>2004</fabricacao>

18 <modelo>2004</modelo>

19 </ano>

20 <anofabricacao>2005</anofabricacao>

21 <opcionais>AQ, LDT</opcionais>

22 <valor>28.900</valor>

23 </carro>

24 </lista>

A linha 01 no documento (declaração XML) define a versão do XML e a codificação dos caracteres usados no documento;
A linha 02 descreve o elemento raiz do documento, como se fosse um título;
Nas linhas 03 a 23 encontram-se os elementos do documento raiz (modelo marca, etc.);
Na linha 24 encontra-se o fechamento do elemento raiz.

Um dado importante no XML é que todos os elementos possuem uma tag de abertura (<modelo>) e uma tag de fechamento (</modelo>), portanto a falta de um deles é considerada ilegal.

Elementos XML podem ter atributos no início da tag, sendo parecido com HTML, sendo utilizados para prover informações adicionais sobre elementos e devem ser utilizados com aspas para serem reconhecidos ex:

<carro placa=”IFZ0578”> <- Modelo Correto

<carro placa=IFZ0578> <- Modelo Incorreto

Atributos geralmente provem informação que não são parte dos dados porem importantes para o software que quer irá manipular o elemento.

2.2.2 Namespace

Namespaces é um método para evitar conflito de nomes de elementos em um documento XML. Como os nomes de elementos são definidos pelo usuário pode acontecer que em um mesmo documento XML exista a coincidência de se utilizar um mesmo elemento para duas situações distintas com semânticas diferentes.

Ex. 01:

<tabela>

<titulo>Lista de Preços de Veículos</titulo>

<conteudo> ... </conteúdo>

</tabela>

Ex. 02:

<tabela>

<largura>100px</largura>

<altura>400px</altura>

<nro_colunas>5</nro_colunas>

<nro_linhas>5</nro_linhas>

</tabela>

Se estes dois documentos XML forem colocados juntos num mesmo documento, existirá um conflito de nomes porque em ambos os documentos existem os elementos <tabela> com definições e conteúdos diferentes.

Para resolver este problema criou-se um sistema para prefixar cada elemento com um valor único. Assim como no exemplo anterior os dois elementos chamados <tabela> poderia ser diferenciados utilizando um prefixo como <abc:tabela> e <xyz:tabela>. Para evitar que outro desenvolvedor utilize o mesmo prefixo adotou-se então que o prefixo utilizado referenciaria uma URL <www.servidor.com.br/xml:tabela>. Para simplificar o código e não retirar a legibilidade humana criou-se então um sistema de alias para a URL. O exemplo abaixo demonstra melhor este método:

<?xml version="1.0" ?>

<abc:root xmlns:abc="http://www.servidor.com.br/tabela1"

xmlns:xyz="http://www.servidor.com.br/tabela2">

<xyz:tabela>

<xyz:titulo>Lista de Preços de Veículos</xyz:titulo>

<xyz:conteudo> ... </xyz:conteúdo>

</xyz:tabela>

<abc:tabela>

<abc:largura>100px</abc:largura>

<abc:altura>400px</abc:altura>

<abc:nro_colunas>5</abc:nro_colunas>

<abc:nro_linhas>5</abc:nro_linhas>

</abc:tabela>

</abc:root>

2.2.3 Esquemas

São arquivos escritos em XML que descrevem os elementos, atributos, valores e tipos de dados válidos para a construção de arquivos XMLs. É atualmente a tecnologia recomendada pela W3C para desenvolvimento de representações de esquemas em XML e substitui a antiga DTD. Suas principais características são:

É baseado no XML.
Determina os elementos e atributos que podem existir no documento.
Permite definir regras de restrição para tipos de dado, elementos e atributos.
Determina a cardinalidade dos elementos.
Suporta a definição de novos tipos de dados (criados pelo usuário).
Permite a reutilização de código (através de namespaces).

Basicamente o usuário pode definir dois tipos de elementos: simples e complexos. Os Elementos simples são definidos pela chave simpleType e os atributos name, Type e restriction.

<xsd:simpleType name=”modelo” type=”xsd:string”/>

<xsd:simpleType name=”anofabricacao”>

<xsd:restriction base=”xsd:positiveInteger”>

<xsd:maxExclusive value=”2006” />

</xsd:restriction>

</xsd:simpleType>

O exemplo acima mostra a definição de dois tipos simples, o primeiro chamado de modelo possui tipo de dados texto (string), o segundo possui o tipo de dados inteiros (integer), porem, só permite a utilização de dados positivos e menores que 2005.

Para definirmos elementos mais complexos (como por exemplo, registros) utilizamos a chave complexType. Em geral os elementos complexos agrupam um conjunto de elementos simples.

<xsd:complexType name=”carro”>

<xsd:sequence>

<xsd:simpleType name=”modelo” type=”xsd:string”/>

<xsd:simpleType name=”marca” type=”xsd:string”/>

<xsd:simpleType name=”anofabricacao” type=”xsd:positiveInteger”/>

<xsd:simpleType name=”opcionais” type=”xsd:string”/>

<xsd:simpleType name=”valor” type=”xsd:positiveFloat”/>

</xsd:sequence>

</xsd:complexType>

Para definição de atributos utilizamos uma estrutura semelhante a anterior, porem, utilizamos a chave attribute. Cada atributo pode ser definido como opcional ou obrigatório e se necessário podem possuir um valor padrão.

<xsd:attribute name=”codigo”>

<xsd:simpleType>

<xsd:restriction base=”xsd:positiveInteger”/>

</xsd:simpleType>

</xsd:attribute>

A utilização de tipos de dados auxilia na compatibilização de sistemas e os mais utilizados são: string, date, time, integer, boolean, float, etc.

2.3 Simple Object Access Protocol (SOAP)

SOAP é um protocolo que define uma estrutura para interoperabilidade entre sistemas através de mensagens XML entre o Servidores e Clientes.

As mensagens SOAP, também chamadas de envelopes, são comumente transmitidos via o protocolo http, mas podem ser transmitidos através de outros protocolos como SMTP, etc. Na visão web, um envelope SOAP é um documento XML, portanto, atravessa facilmente os firewalls e sistemas de segurança o que possibilita transparência e flexibilidade.

Figura 2.2: C omunicação entre sistemas em meio WEB

Sua arquitetura tem sido desenvolvida para ser independente de qualquer modelo particular de sistema e uma das principais características pelo seu sucesso é a extensibilidade.

Acessar objetos é algo simples para compreensão. Chamamos os objetos com intenção de executar seus métodos de forma remota tornando-se assim um sistema distribuído.

A estrutura básica de um envelope SOAP é dividida em:

Um elemento envelope que o identifica como SOAP.
Um elemento cabeçalho (header)
Um elemento com o corpo (body)

A estrutura completa de uma mensagem SOAP é representada no código abaixo:

<?xml version="1.0" ?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header>

…

</soap:Header>

<soap:Body>

…

</soap:Body>

</soap:Envelope>

2.3.1 A tag Envelope

A tag env:Envelope é o elemento raiz da mensagem, seu funcionamento e parecido com o envelope de carta tradicional. Podemos “encher” nosso envelope com o conteúdo a ser remetido e enviar para o destinatário ler e executar o que é solicitado.

Figura 2.3: Envelope SOAP

A demarcação de inicio e fim do envelope SOAP se da com a ocorrência das tags <env-Envelope> e </env:Envelope>.

<?xml version="1.0" ?>

<soap:Envelope

xmlns:soap=”http://www.w3.org/2003/05/soap-envelope”

soap:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”>

…

</soap:Envelope>

A string xmlns é uma palavra reservada do XML utilizado para indicar o namespace evitando assim o conflito entre o nome das tags. O endereço contido no namespace aponta para um endereço web tradicional onde se encontra na verdade a definição da versão e as informações do protocolo.

2.3.2 A tag Header

A tag env:Header é um dos elementos opcionais encontrados nos envelopes SOAP. Quando existente deve aparecer como primeiro elemento no pacote, sua principal função e contér informações utilizadas muitas vezes para definir o comportamento do envelope ou ainda para transmitir credenciais para autenticação, etc.

No protocolo SOAP são definidos três atributos no namesapce padrão: actor, mustUnderstand e encodingStyle. Estes atributos definem como de ser processada a o envelope SOAP.

<?xml version="1.0" ?>

<soap:Envelope xmlns:soap=”http://www.w3.org/2003/05/soap-envelope”

soap:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”>

<soap:Header>

<m:Trans xmlns:m=”http://www.w3school.com/transaction/”

soap:mustUnderstand=”1”>

234

</m:Trans>

</soap:Header>

</soap:Envelope>

O atributo actor é utilizado para encadear Web Services que esse documento necessita passar para ser completamente processado.

O atributo mustUnderstand é utilizado para gerar mensagens de erro caso o Web Services não seja capaz de manipular os campos deste cabeçalho.

O atributo encodingStyle é utilizado para definir os tipos de dados usados no documento.

Como o protocolo SOAP não definiu uma política para o uso de sessões, transações e autenticações. Assim, muitos desenvolvedores incorporaram no cabeçalho suas próprias tags de controle, como o exemplo abaixo:

<soap:Header>

<a:autenticacao xmlns:myAuth=“http://www.servidor.com.br/login”

soap:mustUnderstand=”1”>

<login> admin </login>

<password> xyz12457 </password>

</a:autenticacao>

</soap:Header>

2.3.3 A tag Body

È na tag obrigatória Body que se encontra a mensagem SOAP a ser processada pelo servidor destino. Normalmente consiste em uma chamada a um método do computador remoto com os valores e parâmetros necessários para a execução.

<?xml version="1.0" ?>

<soap:Envelope

xmlns:soap=”http://www.w3.org/2003/05/soap-envelope”

soap:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”>

<soap:Body>

<p:ConsultaPreco xmlns:p=”http://www.servidor.com.br/preco”>

<p:CodigoLivro xsi:type=”XSD:int”>

</p:Livro>

</p:ConsultaPreco>

</soap:Body>

</soap:Envelope>

O atributo xsi:type indica que o valor passado é do tipo integer.

A chamada deste método poderá resultar no retorno de outra mensagem SOAP com os dados obtidos pela chamada ao método.

<?xml version="1.0" ?>

<soap:Envelope

xmlns:soap=”http://www.w3.org/2003/05/soap-envelope”

soap:encodingStyle=”http://www.w3.org/2003/05/soap-encoding”>

<soap:Body>

<p:RetornaPreco xmlns:p=”http://www.servidor.com.br/preco”>

<p:Preco>89.90<p:Preco>

</p:RetornaPreco>

</soap:Body>

</soap:Envelope>

O formato do conteúdo do body fica a cargo de quem está desenvolvendo o Web Services. Veremos adiante que existe um arquivo xml especial para a especificação de como este método deve ser chamado e como ele irá ser retornado: WSDL.

2.3.4 Os tipos de dados

Um dos fatores que dificultam a interoperabilidade de sistemas distribuídos é a dificuldade de representar dados em sistemas distintos. É primordial que ambos os sistemas (cliente/servidor) tratem de maneira igual a tipagem dos dados que estão sendo intercambiamos.

A utilização de dados fortemente tipados traz grandes benefícios de performance podendo ser combinados com outros dados com um grau de confiança mais alto do que dados não tipados. Existe também uma menor chance de evitar confusões entre operações entre dados distintos, evitando assim que o processador tente fazer operações ilógicas como, por exemplo, multiplicar o número de um CPF pelo número qualquer.

Outras diferenças podem ocorrer na troca dos dados, pois, sistemas distintos têm representações distintas para mesmos tipos de dados. Um exemplo típico é o armazenamento do tipo inteiro em diferentes quantidades de bits: 16, 32, 64 bits... Indiferente das quantidades todas as máquinas chamam o tipo de “inteiro”.

Para solucionar este tipo de problema o SOAP atribuiu a tarefa de conversão de dados aos desenvolvedores de serviços. Todas as linguagens de programação em geral possuem de forma bem precisa a manipulação e conversão de tipos de dados em especial os do tipo “string”.

Existem basicamente duas categorias de tipos suportados:

SimpleType: possuí um tipo de dados especifico como inteiros, strings, etc.

ComplexType: possuí um conjuto de SimpleTypes (registro).

Figura 2.4: Conversão entre tipos de dados.

Uma lista mais detalhada dos tipos suportados no SOAP pode ser obtida através dos tipos XML válidos em: http: //www.w3c.org/TR/xmlschema-0/#SimpleTypeFacets.

2.3.5 O retorno de erros

Para detectar possíveis problemas durante a execução de um serviço o protocolo SOAP utiliza a tag fault para o controle e suporte a falhas. Esse elemento é opcional e aparece nas mensagens de resposta. Em sua estrutura a tag fault apresenta quatro formas de utilização.

Faultcode: Elemento obrigatório que indica o código do problema ocorrido.

Faultstring: Versão legível e amigável da informação ocorrida no faultcode.

Faultactor: Traz opcionalmente a informação de quem gerou o problema.

Detail: Traz informações referentes ao estado do servidor na hora da falha.

Em geral no SOAP os erros são representados através de strings onde a primeira parte é a representação do código principal do erro e a segunda parte representa erros secundários.

<soap:faultcode>

Server.ErroAutenticacao

</soap:faultcode>

Os faultcodes definidos pela especificação são:

server: Indica a ocorrência de erros por parte do servidor.

client: Indica a ocorrência de erros com a mensagem.

versionMismatch: Indica a ocorrência de erro quando as versões do protocolo SOAP são diferentes.

mustUnderstand: Erro gerado quando um dos elementos obrigatórios do cabeçalho não é compreendido pelo sistema.

<soap:fault>

<soap:faultcode>

Server.ErroAutenticacao

</soap:faultcode>

<soap:faultstring>

Usuário inválido ou não cadastrado

</soap: faultstring>

<soap:faultactor>

http://www.servidor.com/login

</soap:faultactor>

<soap:detail>

<login>

joao

</login>

</soap:detail>

</soap:fault>

O exemplo acima demonstra um retorno de erro do Web Services.

2.4 Web Services Description Language (WSDL)

O WSDL é um documento no formato XML que especifica as informações necessárias para se conectar a um Web Services. Para que se possa consumir um determinado Web Services é necessário que o cliente detenha o conhecimento de como e quais são os formatos de mensagens que irão ser trocadas com o servidor. A WSDL (WSDL, 2003) foi criada com o objetivo de padronizar estas interfaces de comunicação com o intuito de facilitar o reconhecimento e a troca de dados.

A utilização do XML foi escolhida por ser um formato de fácil compreensão humana e também de fácil processamento para a máquina. A partir deste principio tudo que é necessário para se conectar a um Web Services é o desenvolvimento de parsers XML que extraiam e utilizem as informações da WSDL para conexão. Além das informações referentes à conexão ao Web Services a WSDL contém também informações das operações oferecidas pelo serviço.

Basicamente sempre que um cliente necessita acessar um serviço ele utiliza a WSDL para descobrir como acessa-lo. Para maximizar as potencialidades o desenvolvedor do serviço publica-o em algum diretório de procura para que se torne público de fácil descoberta.

O documento WSDL possuí uma estrutura bem definida sendo subdividido em três partes principais:

· Definição de tipos de dados (determinam a estrutura e o conteúdo das mensagens)

· Operações (determinam as operações disponíveis para o serviço)

· Protocolo de Ligações (determina a forma de transmissão das mensagens pela rede)

2.4.1 Estrutura de um WSDL

WSDL é extensível e permite que para as mensagens não necessitem saber quais os formatos ou protocolos de redes serão utilizados para comunicação.

Figura 2.5: elementos do documento WSDL.

WSDL usa os seguintes elementos em sua definição dos serviços de rede:

2.4.2 O elemento <types>

O elemento types indica que um tipo de dados WSDL está sendo declarado. Esta pratica é muito utilizada devido as restrições impostas pelo protocolo SOAP que especifica somente única entrada ou saída de dados. Para que valores de parâmetros passados não se limitem aos tipos primitivos podemos através deste elemento criar tipos de dados mais especializados como registros personalizados pelo próprio usuário. Este tipo de dados especial é também conhecido como tipo complexo (complexType).

O modelo abaixo exemplifica melhor este conceito:

<carro>

<codigo>1</código>

<modelo>Corsa Sedan</modelo>

<marca>GM</marca>

<anofabricacao>2002</anofabricacao>

<opcionais>AC, DH, TE</opcionais>

<valor>22.500</valor>

</carro>

O exemplo acima ilustra um modelo de registro para um web Services para revenda de carros usados onde um carro possui vários sub elementos que o caracteriza.

Transpassando o exemplo anterior para o modelo WSDL teríamos:

<wsdl:types>

<wsd:schema targetNamespace=”http://www.servidor.com.br/carro.xsd”

xmlns:xsd=”http://www.w3.org/2001/XMLSchema”

xmlns=”http://www.servidor.com.br/carro.xsd”>

<xsd:element name=”carro”>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=”codigo” type=”xsd:integer” />

<xsd:element name=”modelo” type=”xsd:string” />

<xsd:element name=”marca” type=”xsd:string” />

<xsd:element name=”anofabricacao” type=”xsd:integer” />

<xsd:element name=”opcionais” type=”xsd:string” />

<xsd:element name=”valor” type=”xsd:double” />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

</wsdl:types>

2.4.3 O elemento <message>

O elemento message descreve de forma abstrata a definição do tipo de dados que estão sendo enviado/recebido através da mensagem. Estas mensagens podem ser divididas em uma ou mais partes. A divisão em partes poderia ser comparada a passagem de parâmetros a uma função.

O exemplo abaixo demonstra a criação de uma mensagem utilizada para a inserção de um veículo no sistema de cadastro de carros:

<wsdl:message name=”AdicionaCarro”>

<wsdl:part name=”DadosCarro” element=”tns:carro” />

</wsdl:message>

Como retorno poderíamos ter uma mensagem informando se a operação foi executada com sucesso.

<wsdl:message name=”ConfirmaCarro”>

<wsdl:part name=”resposta” element=”xsd:integer” />

</wsdl:message>

2.4.4 O elemento <operation>

Este elemento define de forma abstrata a estrutura de uma operação de chamada a um método remoto .

Existem três mensagens permitidas:

· Mensagem de Entrada;

· Mensagem de Saída;

· Mensagem de Falha;

Existem dois tipos de grupos de operações que podem ser utilizadas. O primeiro grupo define as operações do cliente e o segundo grupo as operações no ponto do vista do Web Services.

No lado cliente temos:

Pedido com Resposta: o cliente realiza um pedido é o Web Services retorna uma resposta a requisição.

Pedido sem Resposta: o cliente realiza um pedido ao Web Services sem a necessidade de uma resposta.

No lado do Web Services temos:

Notificação com Resposta: o Web Services faz uma comunicação ao cliente esperando uma resposta.

Notificação sem Resposta: o Web Services faz uma comunicação ao cliente sem a necessidade de uma resposta.

<wsdl:operation name=”AdicionaCarro”>

<wsdl:input message=”AddCarro” />

<wsdl:output message=”Resposta” />

<wsdl:fault message=”MsgErro” />

</wsdl:operation>

2.4.5 O elemento <portType>

Este elemento é utilizado para agrupar um conjunto de todas as operações de um Web Service.

<wsdl:portType name=”CarroPortType”>

<wsdl:operation name=”AdicionaCarro”>

<wsdl:input message=”AddCarro” />

<wsdl:output message=”Resposta” />

<wsdl:fault message=”MsgErro” />

</wsdl:operation>

...

</wsdl:portType>

2.4.6 O elemento <binding>

O elemento binding é utilizado para definir o formato das mensagens e mapeamento dos elementos operation para cada portType.

<wsdl:binding name=”CarroBinding” type=”CarroPortType”>

<soap:binding style=”rpc”

transport=”http://schemas.xmlsoap.org/soap/htttp” />

<wsdl:operation name=”AdicionaCarro”>

<soap:operation

soapAction=”http://www.servidor.com.br/AdicionaCarro” />

<wsdl:input>

<soap:body use=”encoded”

namespace=”http://www.servidor.com.br/Carro”

encodingStyle=”http://schemas.xmlsoap.org/

soap/encoding/” />

</wsdl:input>

<wsdl:output>

<soap:body use=”encoded”

namespace=”http://www.servidor.com.br/Carro”

encodingStyle=”http://schemas.xmlsoap.org/

soap/encoding/” />

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

O exemplo acima mostra que o binding é do tipo SOAP e irá ser enviada via através do protocolo http. O elemento soap:body detalha como a operação deverá ser codificada.

2.4.7 O elemento <service> e <port>

O elemento port é utilizado para nomear o endereço físico (IP e Porta) que irá ser utilizado para comunicação do Web Services.

<wsdl:port binding=”CarroBinding” name=”CarroPort”>

<soap:address location=”http://www.servidor.com.br:1510/soap/

servlet/rpcrouter”>

</wsdl:port>

O elemento service nada mais é que um elemento de grupo para todas as portas de um documento WSDL.

<wsdl:service name=”CarroService”>

<wsdl:documentation>

Web Services – Anuncio de Carros Usados

</wsdl:documentation>

<wsdl:port binding=”CarroBinding” name=”CarroPort”>

<soap:address location=”http://www.servidor.com.br:1510/soap/

servlet/rpcrouter”>

</wsdl:port>

</wsdl:service>

2.4.8 O elemento <definitions>

É o elemento raiz de um documento WSDL, contém todas as definições globais através do uso de namespaces.

<wsdl:definitions name=”Carro”

targetNameSpace=”http://www.servidor.com.br/carro.wsdl”

xmlns:soap=” http://schemas.xmlsoap.org/wsdl/soap”

xmlns:wsdl=” http://schemas.xmlsoap.org/wsdl/”

xmlns=”http://www.servidor.com.br/carro.xsd”>

...

</wsdl:definitions>

2.5 Universal Discovery, Description and Integration (UDDI)

Quando se desenvolve um Web Services, necessitamos definir entre outros assuntos quem, como, e onde serão utilizados os serviços. Com o avanço da tecnologia e o avanço das prestações de serviços em meio eletrônico criou-se à necessidade de se divulgar, de forma ágil as informações referentes aos serviços a serem prestados. A dificuldade dos desenvolvedores em divulgar seus serviços estava relacionada até então com a divulgação das url(s) para seus novos clientes. Para aumenta a base de clientes não basta ter somente o serviço, é necessário saber onde encontrá-lo.

Uma das maneiras de se acessar o serviço e conhecer o seu URI, o que caracteriza o acesso de forma estática, a outra maneira é fazer com que a aplicação cliente descubra os serviços oferecidos de forma dinâmica.

Com a finalidade de facilitar a localização de Web Services, foi criada a UDDI, tecnologia baseada em iniciativas da Microsoft, IBM entre outras que defende a criação de um banco de dados aberto que permita a busca e a publicação de serviços através de um conjunto de meta-dados específicos. A partir de 2002 o grupo OASIS assumiu o controle do projeto expandindo o número de empresas a apoiar a padronização do sistema.

A UDDI tem como objetivo ser:

· Um mecanismo aberto, padronizado e transparente para descrição de serviços.

· Descrever métodos simples para solicitação de serviços.

· Especificar um registro central acessível dos serviços a serem prestados.

Existe duas formas de interação com os repositórios UDDI, através de interfaces com o usuário oferecidas pelos repositórios de dados ou através de uma API de programação.

O processo de localização (Discovery) consiste em acessar os repositórios (registries) contendo todos os documentos relativos aos dados de negócios. A vantagem de se utilizar os registries e a facilidade de poder localizar todos os serviços públicos que atenda suas necessidades, podendo estes ser comparados e avaliados.

A localização pode ser de forma direta ou indireta. A localização direta consiste em obter dados de um registro mantido por um provedor de serviços. Normalmente os dados oferecidos tendem a ser mais precisos e confiáveis já que a organização que provê as informações tem interesse em prestar bons serviços. A localização indireta se da através de registros de terceiros, porém a garantia de confiabilidade e atualização pode ser comprometida ou sem garantias.

Os provedores de registro de serviços (UDDI Business Registry) são implementações completas das especificações da UDDI que permitem qualquer cliente buscar dados referentes a serviços como também qualquer empresa registrar suas atividades operacionais.

Neste contexto existem três categorias principais:

2.5.1 Páginas Brancas (White Pages)

Contém todas as informações necessárias para contatos como nomes, telefones, e-mails incluindo o D&B DUNS que é a sigla para Data Universal Numbering System (Sistema Universal de Numeração de Dados) mantido pela Dun & Bradstreet. Esta numeração é composta de nove dígitos que identificam de forma internacional as empresas ligadas ao EDI (Eletronic Data Interchange) e suas transações eletrônicas no comércio internacional.

2.5.2 Páginas Amarelas (Yellow Pages)

Contêm as informações baseadas em taxonomias padrões que classificam as empresas de acordo com o seu ramo de negócio.

2.5.3 Páginas Verdes (Green Pages)

Contém as informações técnicas referentes ao serviço oferecido. Com base nestas informações, que podem ser consideradas como uma espécie de dicionário de dados, o desenvolvedor cliente pode preparar a aplicação para acessar o Web Services.

2.5.4 Registro e definições da API

Uma empresa usuária da UDDI necessita registrar-se somente em um provedores de registro. Uma vez registrado as informações referentes ao serviço são replicadas com outros provedores. Assim, uma empresa registra os seus dados em um determinado provedor e este aparece em outros provedores.

Empresas usuárias de UDDI também podem publicar informação em organizações que auxiliam na criação de Web Services, porem estas empresas não hospedam implementações de UDDI Business Registry (modelo de acesso indireto citado anteriormente).

Através da API UDDI é possível construir um diretório distribuído de negócios e serviços; a API utiliza a definição XML, envelopes SOAP e o protocolo HTTP para envio das informações.

Os serviços definidos no documento UDDI são chamados de Type Model ou tMode., Na maioria dos casos o tModel contem o arquivo WSDL que descreve a interface SOAP do Web Services.

Uma das principais vantagens dessa arquitetura é permitir que programas escritos em diferentes linguagens, em diferentes plataformas, comuniquem-se uns como os outros de uma forma padronizada.

3 Implementando Web Services

Uma das principais vantagens dessa arquitetura é permitir que programas escritos em diferentes linguagens, em diferentes plataformas, comuniquem-se uns como os outros de uma forma padronizada.

Quando implementamos um software, normalmente, buscamos informações referentes a softwares já desenvolvidos, formulas ou outros materiais que utilizaremos como guia durante o período de desenvolvimento, No que se diz respeito a desenvolver serviços na Web não se possui a ainda claro nenhuma regra ou guia para a construção de sistemas e muitas vezes nos encontramos confusos com a imensa gama de ferramentas e técnicas.

Desenvolver Web Services dependerá de muitos fatores e experiências obtidas pelas empresas tanto na área técnica e principalmente na área comercial. Este capitulo visa exemplificar uma implementação básica de um sistema na web com bases nos padrões vistos no capitulo anterior. Abaixo apresentaremos alguns itens que ajudarão no desenvolvimento de uma arquitetura SOA.

3.1 Considerações importantes no desenvolvimento de Web Services

Quando se possui uma empresa e negócios em funcionamento, devemos escolher tecnologias que permitam agregar valores aos serviços prestados sem que estes onerem por demais a empresa. Se qual for à tecnologia que seja empregada, devemos conhecer com profundidade os objetivos, relacionamentos, e metas que se deseja atingir para obter assim sucesso no desenvolvimento. Este processo requer conhecimento de todos os documentos envolvidos, atores e clientes, sistemas internos e externos, para que a etapa de definição do sistema seja corretamente analisada, modelada e refinada. Somente apos estas definições poderemos escolher a tecnologia que melhor se encaixa na solução desejada e sem que esta cause impactos negativos. Mantenha sempre em mente que a tecnologia escolhida deve trazer mais benefícios para todos que colaboram de uma maneira ou outra no processo.

Não se pode resolver tudo de uma só vez e nem agradar a todos. Quando se define um domínio de um problema devemos focar em etapas menores e grupos específicos. Não adianta querer resolver todos os problemas de integração e comunicação da empresa em um único serviço. Selecione os problemas mais relevantes e onde a aplicação poderá gerar um impacto maior. Comece com um setor ou algum sistema específico antes de querer envolver a organização como um todo. Os pequenos sucessos conduzem a sucessos maiores e facilitam a estabelecer com maior segurança as questões mais difíceis do projeto como, por exemplo, o tempo de implementação e implantação do serviço.

Não se pode querer tratar de informação se não a compreendemos, assim é extremamente importante identificar toda a semântica da aplicação. Entender todos os meta-dados que existem no seu domínio irá facilitar a compreensão de como os dados influenciam e ou atuam no negocio. Em uma mesma aplicação muitas informações podem ter sentidos diferentes quando tratados por setores diferentes, entender estes relacionamentos facilitará a evitar problemas ou contradições quando ocorrer uma integração com os demais sistemas e serviços da organização.

A primeira etapa para identificarmos a semântica é criarmos uma lista de sistemas da organização. Esta lista determinará quais os repositórios de dados existem e qual é a importância que eles possuem para as aplicações. Todos os esquemas físicos e lógicos do banco de dados poderão ser úteis para identificar os dados dentro do domínio do problema. Entretanto, quando o modelo do esquema e da base de dados não puder dar esta visão precisaremos aprofundar as pesquisas e aplicar outras técnicas para a extração do conhecimento.

Entender os serviços disponíveis é uma tarefa bastante importante, cada serviço difere em muito de outro. Deve ser observado que todas as reivindicações internas nem sempre são interfaces ideais como soluções para serem implementadas devendo ser filtradas.

Liste e alise todos os processos do negócio dentro do seu domínio sendo eles automatizados ou não. Esta lista é importante para descobrir aqueles componentes que são fontes ou consumidores de informações e ainda sob qual forma estão disponíveis. Dentro desta lista poderão aparecer processos confidenciais e cosiderados não compartilháveis ou compartilháveis apenas com os sistemas internos da organização.

No mundo real de hoje as aplicações automatizadas não devem acabar sendo bloqueadas por algum Firewalls qualquer, identifique todos os serviços externos e internos necessários para que se possa retirar o máximo proveito e desempenho. Estes serviços podem variar desde conexões a sistemas de EDI ou com outros Web Services e devem estar bem detalhados para garantir a sua usabilidade. Seus clientes deverão enchergar seu serviço como uma ferramenta útil e que agrega valor ao sistema e não uma mera fonte de dados qualquer.

Entendido todos os conceitos é hora de procurar a tecnologia que melhor se emcaixe na solução do seu sistema. Existem varias propostas e fabricantes que oferecem as mais variadas soluções . Procure comparar cada solução e compare se estão sendo oferecidas dentro dos padrões citados do capitulo anterior. Soluções proprietárias podem até funcionar, mas causam sempre uma forte dependencia ao fabricante e podem trazer dores de cabeça no futuro.

Normalmente sistemas baseados em Web Services são em especial alvos críticos principalmente n a nível de negócios. Consequqntemente testa-los em tempo de uso ou em tempo real pode trazer grandes perdas de credibilidade para sua organização se não for testado adequadamente. Após implementado o serviço elebore planos de teste para avaliar se seu serviço esta realmente dentro das suas espectativas.

3.2 Implementando um Web Services na prática

Os Web Services vem surgindo com a intenção de facilitar a integração de sistemas distintos. Esta tecnologia é uma solução para muitos dos problemas de comunicação encontrados no cotidiano. Sua estrutura facilita o desenvolvimento de sistemas independentes de linguagem ou plataforma e especial trouxeram grandes avanços de conectividade principalmente para os softwares legados.

Para exemplificar na prática esta tecnologia demostraremos nos itens abaixo a implementação de Web Services em algumas das principais liguagens de programação do mercado.

3.2.1 Estudo de Caso

O objetivo deste estudo de caso é demonstrar o desenvolvimento de uma aplicação em Web Services de forma a consolidar os conhecimentos adquiridos ao logo deste trabalho.

Será implementado um sistema simples de consulta a um sistema para venda de carros através da internet. O sistema será composto de uma módulo servidor e um módulo cliente para a consulta de carros. A idéia básica não é aprofundar intensamente em técnicas ou logicas de programação, mas sim, mostrar um exemplo básico de impementação dos dois módulos.

Em nosso modelo de Web Services serão disponibilizados registros referentes a dados de venda de veiculos conforme o modelo de dados abaixo:

DESCRIÇÃ DO REGISTRO DE INFORMAÇÂO DO VEÍCULO:

Create Table ListaDeVenda

(

idcarro INTEGER NOT NULL,

marca CHAR(100) NOT NULL,

modelo CHAR(100) NOT NULL,

ano INTEGER NOT NULL,

opcionais CHAR(100),

valor FLOAT,

contato CHAR(100) NOT NULL,

);

Para a busca das informações será criado o método BuscaVeiculoModelo cujos parametro de entrada será um texto com refrência ao modelo de carro desejado (Ex. Corsa, Uno, Gol...). O retorno deste método será um conjunto de registros que satisfizer os valores passados.

Para o desenvolvimento deste estudo de caso serão abordadas as liguagens JAVA, ASP.NET e PHP cuja utilização vem sido bastate referenciada para o desenvolvimeto de Web Services.

3.2.2 Implementando Serviços com .NET

.NET é a plataforma da Microsoft para desenvolvimento de sistemas que engloba uma variedade de linguagens sob mesmo framework de trabalho. O Dot Net Framework é um ambiente para construir Web Services entre outras aplicações. Basicamente o framework para desenvolvimento de Web Services consiste de três partes principais:

Common Language Runtime.
Framework classes.
ASP.NET.

A plataforma .NET possuí um conjunto de ferramentas de desenvolvimento para construir e utilizar XML Web Services integrada com a Internet. Dentro desta plataforma existem componentes como:

.NET Framework
Visual Studio .NET.
Bilding Bock Services.

Building Block Services é um conjunto de XML Web Services centrados no usuário Esses serviços simplificam e unificam de maneira personalizada a interação entre aplicações, serviços e dispositivos sempre com a garantia de consentimento do usuário.

O .NET utiliza um sistema que distribui o processamento de forma que ele ocorrerá onde fizer maior sentido. O .NET provê suporte a inúmeras formas de distribuir a capacidade de processamento, inclusive a peer-to-peer, para possibilitar que os usuários tirem proveito da capacidade de processamento de seus PCs. Esse costuma ser um modelo de aplicação mais eficiente e que reduz os pontos de estrangulamento das conexões centradas no servidor.

Desconsiderando as questões emocionais referente a utilização de produtos Microsoft os principais motivos dos desenvolvedores adotarem esta tecnologia é devido a:

· Facilidade de uso (poucas ferramentas posuem uma IDE tão rica como o Visual Studio .NET)

· Mercado de Trabalho (o mercado possuí uma grande receptividade para desenvolvedores)

· Documentação (um ponto forte da Microsoft é o volume de documentação disponibilizada para consulta seja ele qual for o produto)

· Suporte (A Microsoft possuí um eficiente sistema de suporte ao seus associados)

Com relação ao desenvolvimento de Web Services a estrutura .NET possue um conjunto de classes específicas para o desenvolvimento e tratamento de aplicações. As principais classes disponíveis são:

System.Web.Services:	Fornece Suporte SOAP para clientes e servidores.
System.Timers:	Serviços de Temporização.
System.Collections:	Tratamento de coleções como listas, tabelas, etc.
System.Net:	Suporte para redes.
System.Threading:	Suporte para programação multitarefa.
System.Drawing:	Suporte para gráficos 2D.
System.Runtime.Serialization:	Suporte para codificação binária e SOAP.
System.Security:	Serviços de Segurança.
System.Criptography:	Serviços de criptografia de dados.

A implementação dos exemplos exemplos citados abaixo presupoem a existência do servidor Web IIS, a instalação da plataforma .NET e o uso da ferramenta Visual Studio.NET.

Na plataforma. NET a implementação básica de um servidor é bastante simples, utilizaremos o Visual Studio .Net como ferramenta de desenvolvimento. Os passos para a criação do servidor estão descritos abaixo:

Escolha novo projeto e selecione a opção ASP.NET Web Services como demonstrado na figura abaixo.

Figura 3.1: Escolha do projeto.

A primeira item a ser observado é a extensão do arquivo, para Web Services o.NET utiliza o .asmx, O propósito então é criar um componente para que outras aplicações possam acessar. O desenvolvimento do serviço será efetuado no arquivo Service1.asmx conforme a imagem abaixo:

Figura 3.2: Formulário de Desenvolvimento do Serviço

Dentro do formulário efetuaremos a programação do serviço conforme a codificação abaixo:

Imports System.Data.OleDb

Imports System.Web.Services

<System.Web.Services.WebService _

(Namespace:="http://localhost/veiculos/service1")> _

Public Class ListaVeiculos

Inherits System.Web.Services.WebService

<WebMethod(Description:="Consulta Veículos por Modelo")> _

Public Function BuscaVeiculoModelo(ByVal strValor As String) _

As DataSet

Dim conn As New OleDbConnection()

Dim cmd As New OleDbCommand()

Dim da As New OleDbDataAdapter()

Dim ds As New DataSet()

Dim strBusca As String

Dim strSQL As String

strSQL = "Select * from ListaVeiculos "

if (strValor <> "")

strSQL = strSQL & " where modelo like '%" & strValor & "%'"

end if

strConn = "Provider=Microsoft.JET.OLEDB.4.0;”

strConn = strConn & "Data Source=C:\veiculos.mdb"

conn.ConnectionString = strConn

cmd.Connection = conn

cmd.CommandText = strSQL

da.SelectCommand = cmd

da.Fill(ds)

conn.Dispose()

cmd.Dispose()

da.Dispose()

Return ds

End Function

End Class

Observando o código apresentado fica claro que a implementação do Web Services b não possui diferenças para o desenvolvimento de uma classe padrão.Para executar o Web Services basta acessar a url do servidor. O resultado da execução será:

Figura 3.3: Acesso ao Web Services

Seu Web Services esta implementado, podemos consumi-lo com qualquer aplicação que tenha suporte a Web Services.

Para implementar um cliente em .Net não necessitamos praticamente nenhum esforço visto que já esta tudo pronto no servidor. Para exemplificar o acesso ao cliente criaremos uma aplicação utilizando o VB.NET.

O codigo abaixo demostra a programação necessária para acessarmos o cliente

Imports System.Data.OleDb

Imports System.Web.Services

Public Class Cliente Inherits System.Windows.Forms.Form

[+][Windows Form Designer generated code]

Private Sub btnBusca_Click (ByVal sender As System.Object, _

ByVal e As System.EventArgs) _

Handles btnBusca.Click

Dim ws As New localhost.ListaVeiculos()

' Chamando o Web Services

Dim ds As New DataSet()

' Criando um Data Set para guardar os dados retornados

' no Web Services

ds = ws.BuscaVeiculoModelo(txtModelo.Text)

' Chamando o Método Remoto do Web Services

Grid.DataSource = ds.Tables(0)

Grid.Refresh()

End Sub

End Class

A tela abaixo demonstra uma interface básica para consulta.

Figura 3.4: Cliente acessando Web Services

3.2.3 Implementando Serviços com JAVA

O desenvolvimento de Web Services com Java teve seu inicio graças a introdução da arquitetura J2EE que permitiu o desenvolvimento de aplicações distribuídas e no formato multicamada.

Os componentes do J2EE foram produzidos para que o desenvolvimento de aplicações seja produtivo e simples. O sucesso no uso do J2EE se deve ao seu modelo de mapeamento que consegue extrair toda a funcionalidade da aplicação e o controle do serviços providos pelos containers de forma organizada e padronizada.

A plataforma J2EE possuí suporte para as duas especificações, J2EE e Web Services, permitindo assim que aplicações desenvolvidas com o J2EE possam se tornar Web Services sem a perda das caracteristicas originais. O J2EE fornece um número grande APIs, o que simplifica e expande as possibilidades no desenvolvimento de sistemas garantindo a interoperabilidade de serviços e protocolos. Outro ponto forte da arquitetura e provêr um mecanismo de escalabilidade para aplicações distribuídas incluindo suporte a transações, conexões a banco de dados, controle de requisições sem a necessidade de honerar o código da aplicação a ser escrita. O modelo de segurança é planejado para ser flexível, permitindo que componentes possam ser disponibilizados aos usuários através de regras de permissões que permitam a utilização sem perda de segurança.

A partir da arquitetura J2EE foi possível criar e manter uma série de tecnologias para serviços, ferramentas e componentes fundamentais para a sua própria existência. As empresas e a comunidade em geral tem participado ativamente para o desenvolvimento de novos recursos e nos esforços para manter a arquitetura J2EE em conformidade com as APIs dos Web Services, facilitando principalmente a interoperabilidade e escalabilidade dos mesmos.

Existem vários projetos em andamento para o desenvolvimento de serviços com Java. Entre os mais utilizados encontram-se o AXIS (Apache Extensible Interaction System). Este framework em JAVA que prove recursos para a construção de processos SOAP em clientes, servidores e gateways.

As principais característica do Axis são:

· Simples Servidor Standalone.

· Servidor com plugin para trabalhar dentro de engines como o Tomcat

· Possui ferramentas para monitorar o pacotes TCP/IP e suporte para o SOAP 1.1/1.2

· Flexível configuração e suporte para rápidos deploys de serviços.

· Suporte para transmissão de tipos primitivos e tipos de dados definidos pelos usuários (type mapping).

· Suporte automático para transmissão de Java Beans e conversão automática de Java Collections para SOAP Arrays.

· Geração automática do WSDL para deploy de serviços.

· A ferramentas para a criação de classes Java a partir de documentos WSDL (WSDL2Java) ou a construção de documentos WSDL a partir das classes Java (Java2WSDL).

A implementação dos exemplos exemplos citados abaixo presupoem a existência do servidor Web Tomcat, a instalação do pacote AXIS e o uso de uma ferramenta de programação Java como o JCreator.

A plataforma AXIS implementa a API JAX-RPC, sendo uma das maneiras de se programar serviços em JAVA. A plataforma AXIS está diponibilizada sob forma de um pacote JAR (Axis.jar) onde estão incluídas diversas bibliotecas que comtemplam os elementos necessários para o seu funcionamento como a JAXRPC.

Figura 3.5: Estrutura do Servidor Web Tomcat e o pacote AXIS

Para o desenvolvimento de um Web Services é necessário a instalação dos arquivos dentro do diretório “classes” localizado sob o diretório WEB-INF do AXIS. As classes colocadas no diretório <Tomcat>/axis/WEB-INF/classes, formam o serviço web sendo ainda necessária a configuração do AXIS para a publicação do serviço web. A plataforma Axis utiliza um arquivo chamado WSDD (Web Service Deployment Descriptor), que mostra as características do serviço web.

Abaixo encontram-se a implementação do serviço citado no estudo de caso baseado no framework do AXIS.

A classe Veiculo implementa o objeto serializavel que será passado na chamada o serviço e a classe ListaVeiculos implementa o serviço (servidor).

//Classe Veiculo

public class Veiculo implements java.io.Serializable

{

private int idcarro;

private String marca;

private String modelo;

private int ano;

private String opcionais;

private float valor;

private String contato;

public Veiculo() {}

public Veiculo(int p1, String p2, String p3,int

p4,String p5,float p6,String p7)

{

idcarro = p1;

marca = p2;

modelo = p3;

ano = p4;

opcionais = p5;

valor = p6;

contato = p7;

}

public int getIdcarro() { return idcarro; }

public String getMarca() { return marca; }

public String getModelo() { return modelo; }

public int getAno() { return ano; }

public String getOpcionais() { return opcionais; }

public float getValor() { return valor; }

public String getContato() { return contato; }

public void setIdcarro(int p) { idcarro = p; }

public void setMarca(String p) { marca = p; }

public void setModelo(String p) { modelo = p; }

public void setAno(int p) { ano = p; }

public void setOpcionais(String p) { opcionais = p; }

public void setValor(float p) { valor = p; }

public void setContato(String p) { contato = p; }

private java.lang.Object __equalsCalc = null;

public synchronized boolean equals(java.lang.Object obj)

{

if (!(obj instanceof Veiculo)) return false;

Veiculo other = (Veiculo) obj;

if (obj == null) return false;

if (this == obj) return true;

if (__equalsCalc != null) {

return (__equalsCalc == obj);

}

__equalsCalc = obj;

boolean _equals;

_equals = true &&

this.ano == other.getAno() &&

((this.contato==null && other.getContato()==null) ||

(this.contato!=null &&

this.contato.equals(other.getContato()))) &&

this.idcarro == other.getIdcarro() &&

((this.marca==null && other.getMarca()==null) ||

(this.marca!=null &&

this.marca.equals(other.getMarca()))) &&

((this.modelo==null && other.getModelo()==null) ||

(this.modelo!=null &&

this.modelo.equals(other.getModelo()))) &&

((this.opcionais==null && other.getOpcionais()==null) ||

(this.opcionais!=null &&

this.opcionais.equals(other.getOpcionais()))) &&

this.valor == other.getValor();

__equalsCalc = null;

return _equals;

}

private boolean __hashCodeCalc = false;

public synchronized int hashCode()

{

if (__hashCodeCalc) {

return 0;

}

__hashCodeCalc = true;

int _hashCode = 1;

_hashCode += getAno();

if (getContato() != null) {

_hashCode += getContato().hashCode();

}

_hashCode += getIdcarro();

if (getMarca() != null) {

_hashCode += getMarca().hashCode();

}

if (getModelo() != null) {

_hashCode += getModelo().hashCode();

}

if (getOpcionais() != null) {

_hashCode += getOpcionais().hashCode();

}

_hashCode += new Float(getValor()).hashCode();

__hashCodeCalc = false;

return _hashCode;

}

// Type metadata

private static org.apache.axis.description.TypeDesc typeDesc =

new org.apache.axis.description.TypeDesc(Veiculo.class, true);

static

{

typeDesc.setXmlType(new javax.xml.namespace.QName("", "Veiculo"));

org.apache.axis.description.ElementDesc elemField = new

org.apache.axis.description.ElementDesc();

elemField.setFieldName("ano");

elemField.setXmlName(new javax.xml.namespace.QName("", "ano"));

elemField.setXmlType(new

javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema",

"int"));

elemField.setNillable(false);