LEONARDO CEZAR DE FREITAS
RA: 032.333
WEB SERVICES
FACULDADE DE TECNOLOGIA DE AMERICANA
2006
LEONARDO CEZAR DE FREITAS
RA: 032.333
WEB SERVICES
Monografia apresentada ao curso de Tecnologia
em Processamento de Dados da Faculdade de
Tecnologia de Americana – FATEC AM como
parte da matéria EAPS.
Orientador: Profº Sergio Roberto Sigrist
FATEC - AMERICANA
SEGUNDO SEMESTRE DE 2006
II
Dedico
este
trabalho
a
todos
os
profissionais da área de Tecnologia da
Informação,
que
com
seus
esforços
contribuem para cada vez mais consolidar
reconhecimento de nossa profissão.
Agradecimentos
Ao Prof. Sergio Roberto Sigrist
Por aceitar e orientar-me nesta monografia.
Aos Professores da Faculdade de Tecnologia de Americana
Por todo o trabalho executado com o objetivo de ensinar-me.
IV
"O fator decisivo para vencer o maior
obstáculo é, invariavelmente, ultrapassar o
obstáculo anterior."
Henry Ford
V
Resumo
Web Services é uma tecnologia nova, mas sua aceitação é grande e encontra-se
presente em muitas plataformas de aplicativos. Com o apoio de grandes corporações
de software existentes no mercado, como Microsoft, IBM, Sun e BEA, esta tecnologia
tem mostrado sua capacidade em atender às novas necessidades tecnológicas e
também dos negócios: promover uma integração de funcionalidades ao mesmo tempo
em que oferece escalabilidade, padronização e baixo custo de implementação e
manutenção.
Atualmente, um profissional que atue diretamente com desenvolvimento de
software, ou mesmo aquele que mantém infraestruturas tecnológicas, e principalmente
os diretores e gerentes das empresas, sejam elas de TI ou não, devem reconhecer o
potencial de Web Services e estudá-lo, porque ele promete ser item muito importante
na evolução da TI corporativa.
Este trabalho tem o objetivo de apresentar os elementos e tecnologias
essenciais para o funcionamento dos Web Services, bem como também mostrar o
impacto e os resultados que o Web Services vem causando nos negócios das
empresas.
VI
Abstract
Web Services is a new technology, but its acceptance is great and its present
today in many application platforms. With the support of big companies existents in the
market, like Microsoft, IBM, Sun and BEA, this technology has showed its capacity to
supply the technological and business needed: to promote an integration of
functionalities ate the same time that offers scalability, standardization and lowers costs
of implementation and maintenance.
Actually, a professional who works directly in software development, even those
who maintains technological infrastructures, companies CIOs and top staff, are they of
IT department or not, they must accept the potential of the Web Services technology
and study it, because it is the next chapter in the evolution of corporative IT.
The major objective of this paper is present the elements and essential
technologies that makes Web Services functional, and to show the impact of the results
that Web Services have been making in the companies business today.
VII
Sumário
1. Introdução ...................................................................................................
9
2. SOA – Service Oriented Architecture ......................................................... 10
3. O Web Service ............................................................................................ 14
3.1 Esquema de funcionamento de um Web Service ................................... 15
4. Tecnologias ................................................................................................ 17
4.1. Protocolo HTTP……………………………………………………………... 17
4.2. XML – Extensible Markup Language …………………………………….. 22
4.3. SOAP – Simple Object Access Protocol …………………………………. 26
4.3.1 Exemplos de mensagens SOAP ....................................................... 27
4.3.1.1 Envio de uma solicitação de execução de um Web Service ........ 27
4.3.1.2 Resposta de uma solicitação de execução de um Web Service .. 28
4.4 WSDL – Web Service Description Language …………………………… 30
4.4.1 Estruturas do WSDL ........................................................................ 31
4.5 - UDDI - Universal Description, Discovery and Integration …………… 33
4.5.1 O UDDI Business Registry (UBR) ……………………………….…… 35
5. SOA, Web Services no ambiente de negócios ........................................... 36
5.1 Benefícios .............................................................................................. 37
5.2 Limitações e aspectos críticos ............................................................... 39
6. Conclusão ................................................................................................... 40
7. Bibliografia .................................................................................................. 41
1. Introdução
Web Services (ou Serviços Web) tem se apresentado como uma nova e
importante tecnologia de computação neste começo de século. Todas as maiores
empresas de software do mundo estão desde o momento da especificação desta
tecnologia promovendo seu uso, crescimento e até mesmo a adoção destes em suas
plataformas de desenvolvimento de softwares, como é o caso da estratégia adotada
pela plataforma Microsoft.NET, que desde do inicio foi promover um ambiente
integrado de desenvolvimento de componentes que pudessem utilizar Web Services de
uma maneira quase que nativa.
Mas não é somente pelo fato de ser uma nova tecnologia que tem feito do Web
Services um nome tão falado na industria de TI. Através de sua proposta de
funcionamento, que é a de integrar funcionalidades e reutilizar rotinas, tornando os
softwares automatizados, distribuídos, gerenciáveis e escaláveis, o Web Services
atingiu de maneira certeira a estratégia de muitos gerentes e diretores da área de TI: a
de utilizar uma plataforma já existente de aplicativos, mas provendo sua integração e
distribuição de uma maneira simples, utilizando conjuntos de hardwares e softwares
existentes. O resultado é uma sinergia de esforços e redução de muitos custos.
Neste trabalho de pesquisa será apresentado no segundo capítulo o que é uma
arquitetura orientada a serviços. É importante primeiramente entender os conceitos
envolvidos neste tipo de arquitetura, pois o Web Services nada mais é do que uma
implementação desta.
O capítulo três será exclusivamente voltado para a apresentação do Web
Services, mostrando seus detalhes e composições internas e citando as tecnologias
que são utilizadas como base para seu funcionamento. Cada uma das tecnologias
apresentadas será explicada em detalhes através do capitulo quatro.
No ultimo capítulo deste trabalho serão comentados o impacto do Web Services
no mundo corporativo, alguns casos de uso da tecnologia e os principais benefícios e
aspectos críticos (ou até problemáticos) dos serviços web.
2. SOA – Service Oriented Architecture
Antes de mostrar o Web Services em detalhes, é preciso apresentar o conceito
tecnológico no qual este é baseado. Desta maneira, compreende-se que o Web
Services não é um elemento novo e diferente. Ele baseia-se no conceito de aplicações
orientadas a serviço, a arquitetura SOA.
De acordo com uma definição da IBM [1], “SOA é um estilo de arquitetura de
softwares que visa interligar os negócios da empresas através de uma rede de
comunicação. A rede de comunicação pode existir inteiramente no mesmo escritório,
ou podem estar dispersas geograficamente, e até mesmo tecnologicamente,
combinando serviços de negócio rodando em escritórios em cidades distantes. Ao
mesmo tempo, estes serviços podem estar rodando também em seu próprio
computador”.
Figura 1: Evolução das arquiteturas de aplicações de Tecnologia de Informação
A figura 1 mostra a evolução das arquiteturas de software desde o inicio da década
de 80, quando surgiram os primeiros aplicativos comerciais, que rodavam somente em
um computador, em uma época em que não existia o conceito de servidor de banco de
dados ou servidores de aplicações.
O esquema mostra também os modelos de arquitetura de software que dominaram
a década de 90, quando foi introduzido o conceito de cliente e servidor. Nestes anos,
os softwares que foram desenvolvidos executavam em estações de computadores
distribuídas dentro da empresa, e utilizavam um servidor de dados banco de dados
para centralizador e armazenar as informações.
Com o boom da Internet no início do século XXI, as empresas tiveram a
necessidade de desenvolver softwares mais flexíveis, para que pudessem rodar em
varias plataformas, tanto a parte servidora quando a parte cliente. Foi então que houve
mais uma divisão, dando origem a arquitetura três camadas: os softwares passaram a
serem compostos pela interface, ou camada de apresentação, onde o usuário grava e
consulta os dados; a camada de negócio, responsável por tratar os dados que são
gravados ou consultados pelo usuário, que pode rodar no mesmo computador ou até
então em servidores de aplicativos específicos para tal finalidade; e finalmente, a
camada de banco de dados, que fica indisponível para a interface, podendo ser
manipulada somente pela camada de negócio.
O modelo de três camadas foi amplamente difundido e ainda hoje é o modelo
predominante nos ambientes de softwares das grandes corporações.
O modelo mais recente é o modelo orientado a serviços. Este divide a camada de
negócio da arquitetura três camadas em duas partes: uma primeira, que seriam os
processos, são as mesmas funcionalidades que já existiam na camada de negócio; e
uma segunda, a de funções, permite a camada de negócio interagir com outras
camadas de negócio de outros aplicativos, localizados no mesmo ambiente de
execução ou até mesmo em ambientes de execução remotos, distribuídos na Internet
ou na rede privada da companhia.
Prova-se que uma arquitetura orientada a serviços vem a agregar funcionalidades
numa arquitetura existente, mas não substituí-la por completo.
Numa visão objetiva, para existir uma arquitetura SOA, basta existirem as
aplicações clientes, que são as entidades que buscam serviços e invocam sua
execução, e os servidores responsáveis por prover estes serviços, gerenciarem sua
execução e devolverem os resultados às solicitações dos clientes. Esta interação entre
as aplicações clientes e os provedores de serviços deve ocorrer dentro de um canal de
comunicação, e os dados transferidos devem ser transcritos em um protocolo
especifico da arquitetura SOA empregada.
Atualmente, existem diversos tecnologias para o desenvolvimento de um ambiente
de software orientado a serviços, como por exemplo, CORBA, RMI, DCOM. Estes que
foram citados precisam rodar em portas especiais de comunicação, o que pode
invalidar o software, dependendo da infraestrutura de comunicação existente.
É
justamente nesta deficiência que o Web Service leva grande vantagem, porque ele
transmite uma mensagem XML utilizando HTTP como agente de transporte, através
apenas portas padrões de comunicação, o que permite uma simples implementação
mesmo em uma rede de comunicação cheia de restrições de segurança.
O modelo de funcionamento do SOA permite aos administradores de TI expandirem
a oferta de serviços, para atenderem novas rotinas de negócios, ou mesmo melhorar a
qualidade das aplicações, atualizando hardware e sistema operacionais, sem prejudicar
o funcionamento de todo o ambiente já em execução.
Do
ponto
de
vista
técnico,
uma
arquitetura
SOA
permite
um
grande
reaproveitamento de rotinas e códigos de aplicativos já existentes (apenas sendo
necessário criar as interfaces para estes no ambiente de serviços) e também melhorar
o serviço, alterando plataforma de funcionamento ou hardware, sem que sejam
necessárias alterações na aplicação cliente, e também este não note diferença alguma.
Em um ambiente orientado a serviço, é recomendado que cada serviço seja
proprietário de si mesmo, ou seja, o serviço deve conter uma parte dedicada a sua
execução e funcionamento (o componente, programa ou executável), e também sua
declaração de interface, que permite aos programas clientes saberem como interagir
com ele. Desta maneira, um aplicativo que solicita determinado serviço precisa apenas
acessar a interface para compreender como invocar determinada rotina oferecida por
ele.
Olhando numa perspectiva de gerencia de TI, utilizar uma arquitetura SOA traz,
entre outros benefícios:
-
alinhamento entre a área de negocio e a área de TI. Como a arquitetura de
funcionamento é orientada a serviços, fica simples para área de TI mapear os
serviços que atendem cada regra de negócio da companhia;
-
aumenta a padronização dos processos existentes no legado de sistemas
corporativos;
-
permite uma centralização do controle corporativo. Note que mesmo com
serviços em locais distribuídos, o gerenciamento destes pode ser centralizado.
Mas a utilização de uma arquitetura de softwares orientada a serviços exige um
grau de entendimento muito maior sobre os negócios ao que, por exemplo, o
conhecimento necessário para o desenvolvimento em uma arquitetura cliente/servidor.
Pelo fato de utilizar serviços, e cada serviço contemplar uma rotina de negócio
específica, caso esta rotina não tenha sido compreendida totalmente, ou até mesmo,
se o todo no qual está inserida rotina não foi totalmente estudado e separado, poderá
resultar na implementação de um serviço que funcionará incorretamente, ou será
insuficiente, necessitando na criação de mais e mais serviços, que muitas vezes
deixarão de ser executados, gerando uma carga desnecessária ao ambiente de
execução.
3. O Web Service
Web Services é um padrão de comunicação, que atende as necessidades de uma
arquitetura baseada em serviços, e tem como principal objetivo promover a
comunicação entre diferentes softwares e aplicações [2], rodando em uma variedade
indeterminada de plataformas. Web Services contempla sozinho a implementação de
uma arquitetura de SOA.
O Web Services apresenta-se como uma forte de tendência no desenvolvimento de
softwares distribuídos, sendo a tecnologia que mais ganha espaço. Isto é devido a sua
simplicidade e versatilidade, e também pelo fato que de basear-se em tecnologias já
consolidadas e amplamente difundidas.
A arquitetura básica inclui tecnologias e padrões [3] capazes de:
- trocar mensagens;
- descrever Web Services;
- publicar e descobrir Web Services.
A implementação de um Web Service é baseada em um conjunto de protocolos e
linguagens padrões de Web, das quais podemos destacar:
- o HyperText Transfer Protocol (HTTP);
- o Simple Object Access Protocol (SOAP);
- o Web Service Description Language (WSDL);
- e o UDDI (Universal Description, Discovery and Integration).
O formato XML é a base dos três últimos elementos citados: SOAP, WSDL e UDDI.
3.1 Esquema de funcionamento de um Web Service
Figura 2: Macro-esquema de funcionamento da tecnologia Web Service
A figura 2 representa o macro-esquema de funcionamento de um Web Service. O
ponto inicial na figura é o Service Requester, que representa a aplicação cliente
(solicitante do serviço). O próximo agente é o Service Broker, que é o publicador de
serviços. O último processo ocorre no Service Provider, que é onde efetivamente existe
o Web Service.
Em eventos, o funcionamento segue-se da seguinte maneira:
-
o Service Requester efetua uma solicitação ao provedor de localizações
(Service Broker), informando o serviço que deseja executar;
-
Service Broker devolve ao Service Requester a localização do provedor de
serviço, bem como as informações em detalhes necessárias para sua
execução;
-
Service Requester invoca o serviço controlado por Service Provider, enviando
para ele uma mensagem SOAP;
-
o Service Provider devolve a mensagem para Service Requester, utilizando
também o padrão SOAP.
O canal de comunicação e transporte entre o aplicativo solicitante e o fornecedor do
serviço é o protocolo HTTP (Hyper Text Transfer Protocol). Este foi estabelecido no
princípio da Internet moderna, com o objetivo de disseminação mais simples de
arquivos texto através da rede mundial de computadores.
Além do HTTP, o padrão Web Service utiliza o SOAP (Simples Object Access
Protocol) como padrão para transmissão de mensagens. O SOAP nada mais é que um
conjunto de instruções formatadas em XML, contendo informações relevantes para a
execução de determinado serviço, que serve também para formatar uma estrutura que
permita aos serviços devolverem informações processadas e estruturadas aos
aplicativos clientes.
A funcionalidade de descobrimento de um serviço é implementada pelo padrão
UDDI (Universal Description, Discovery and Integration). Este tem o poder de tornar um
Web Service público. Desta maneira, podem existir na Internet repositórios UDDI, e
sempre que um desenvolvedor desejar utilizar uma rotina já existente, ele pode buscála em um Web Service que a implemente através da interface de pesquisa do UDDI, e
caso encontre um serviço que satisfaça sua necessidade, poderá então utilizá-lo.
Para descrever um Web Service, ou seja, para apresentar suas interfaces,
métodos, parâmetros e regras de execução, utiliza-se o protocolo WSDL, que significa
Web Service Description Language. Através dele, os aplicativos que irão interagir com
um Web Service podem entender como fazê-lo de maneira automática.
Nos próximos capítulos deste trabalho de pesquisa descreverão em detalhes cada
uma destas tecnologias, que são essenciais para a montagem e funcionamento de um
Web Service.
4. Tecnologias
4.1. Protocolo HTTP
Na Internet, a transmissão de dados ocorre através protocolos distintos, cada
qual com sua finalidade. Por exemplo: para a transmissão de arquivos, existe o
protocolo FTP; para a transmissão de mensagens eletrônicas (e-mail), existe o SMTP e
o POP3; e muitas outras. A grande maioria dos protocolos de comunicação estão sob
responsabilidade do W3C 1.
O HTTP é sigla para Hypertext Transfer Protocol. Trata-se de um protocolo de
nível de aplicativo para distribuir informações em formatos hipermídia
2
. Com a
evolução da internet, o HTTP foi adotado como genérico, tornando-se um protocolo que
pode ser usado para muitas tarefas além do uso em hipermídia, permitindo aos
sistemas construírem formas independentes para transmitir dados. O HTTP é utilizado
como padrão para transferência de documentos pela World Wide Web desde 1990. A
versão atual de HTTP é a 1.1, deferida através do W3C em Junho de 1999, pela RFC
3
2616.
O protocolo de comunicação HTTP consiste em uma série de comandos entre o
aplicativo cliente e servidor. Através destes comandos, ocorrem as transmissões de
dados, em ambos os sentidos. No caso do aplicativo cliente, este transmite
informações para o servidor, utilizando os métodos GET e POST, e no caso do
servidor, este processa as informações enviadas pelo aplicativo cliente e devolve os
dados pelo mesmo canal de comunicação.
1
W3C. World Wide Web Consortium. Entidade sem fins lucrativos que tem o objetivo de coordenar as
ações na World Wide Web (ou Internet).
2
Hipermídia, do inglês hypermedia: é um termo criado em 1965 por Ted Nelson, e é utilizado como
extensão do termo hypertext, onde gráficos, áudio, vídeo, textos planos e hyperlinks interagem-se para
criar uma forma não linear de informação. http://en.wikipedia.org/wiki/Hypermedia, em 10 de outubro de
2006.
3
RFC – Sigla de Request For Comments. Especificações de padrões W3C são documentos colocados
ao público como recomendação, para que o mesmo possa ser melhorado de maneira democrática.
Desta maneira, não importa qual é a plataforma de software cliente ou servidor,
e vice-versa, pois todos os softwares para HTTP devem seguir a especificação W3C.
Nota-se então a possibilidade de troca de informações entre as mais diferentes
plataformas, de forma transparente.
Uma requisição HTTP deve conter:
- o tipo de solicitação, sendo os mais comuns, o GET e POST;
- o objeto que está sendo solicitado;
- uma lista de pares de comandos, que são os valores de cabeçalhos;
- os parâmetros, ou dados, que estão sendo enviados ao servidor. Fica opcional
o envio ou não destes dados.
O trecho abaixo mostra um exemplo de uma requisição HTTP:
1: POST /sistemas/cadatro.asp HTTP/1.1
2: Host: www.empresa.com
3: Content-Type: text/xml; charset=utf-8
4: Content-Length: length
5:
6: Nome=Josias&Idade=21
Analisando linha a linha a mensagem HTTP apresentada, temos os seguintes
itens:
- linha (1): no protocolo HTTP, esta linha deve informar qual o tipo de solicitação
que está sendo efetuando, qual objeto que está sendo solicitado e qual a versão
de HTTP da mensagem. No caso, o tipo de solicitação é o POST, o objeto é
/sistemas/cadastro.asp e a versão do HTTP é a 1.1.
- linhas (2) a (4): estas linhas representam o que é chamado de cabeçalho
HTTP. Um cabeçalho HTTP pode conter mais linhas, caso necessário. Cada
linha do cabeçalho HTTP contém um atributo e seu valor. Os atributos podem
ter os mais diversos significados, como indicar o tamanho da mensagem, o tipo
de dados, identificação do usuário, características da conexão, e muitos outros,
todos especificados pela RFC 2616.
- linha (6): a partir desta linha, é colocada a informação que está sendo enviada
para o servidor. Este trecho da mensagem é livre para uso pelo aplicativo
cliente, podendo colocar o quanto precisar de dados.
Uma resposta HTTP tem uma estrutura semelhante ao de uma requisição,
conforme é mostrado a seguir:
1: HTTP/1.1 200 OK
2: Content-Type: text/xml; charset=utf-8
3: Content-Length: length
4:
5: <html><body>Os dados foram processados</body></html>
Observa-se que a linha (1) agora é tomada com a informação sobre a versão do
HTTP, um status code (que será explicado a seguir) e sua mensagem. Em seguida,
vem o trecho de cabeçalho HTTP, seguido pelo trecho de dados. No trecho de dados,
são colocadas as informações que resultaram do processamento do objeto
anteriormente solicitado.
Uma resposta HTTP gerada pelo servidor deve necessariamente conter um
código. Os cabeçalhos, ou o trecho de informação, em alguns momentos, podem não
ser tão importantes. Mas é o status code (ou código de status) o elemento mais
relevante. O código de status indica se a solicitação do cliente foi processada com
sucesso, se houve algum erro, ou mesmo se o objeto não foi encontrado.
Logo abaixo, segue uma tabela com o principal status codes possíveis de uma
resposta HTTP:
Código Significado
404
O recurso informado através da URL não foi encontrado no servidor.
500
Ocorreu um erro interno no servidor durante o processamento.
403
O acesso ao recurso solicitado através da URL foi negado.
200
O objeto foi encontrado, processado e a resposta devolvida para o
cliente.
Um esquema de troca de informações através de protocolo HTTP está
exemplificado na figura 3:
Cliente
Servidor Web
Pacote de comandos
POST / GET
Recebimentos de
comandos POST / GET
Recebimento da
resposta
Processamento do
comando
Figura 3: Esquema de troca de dados no protocolo HTTP
Todo o fluxo de eventos ilustrado no na figura 3 acontece de maneira síncrona, ou
seja, desde o estabelecimento da conexão efetuado pelo aplicativo cliente, até a
resposta HTTP enviada pelo servidor, todos os eventos são feitos em seqüência. Desta
maneira, os dados são enviados e recebidos pela mesma conexão criada pelo
aplicativo cliente.
Ainda sobre o esquema anterior, se aplicarmos o mesmo no contexto de
execução de um serviço web, podemos obter a seguinte configuração de eventos:
1) determinado Web Service será solicitado pelo aplicativo solicitante (um cliente
HTTP), que atuará como o consumidor do serviço;
2) para invocar determinado serviço, o aplicativo primeiramente localiza o serviço,
utilizando o padrão de endereçamento de Internet chamado URL4;
3) Uma URL precisa ser hospedada em um servidor (um servidor HTTP). Quando
localizada, é estabelecida a comunicação entre o aplicativo cliente e o servidor,
que passam então a trocar os comandos HTTP, conforme a especificação W3C;
4) O cliente monta o comando POST ou GET, para solicitar a execução, colocando
os comandos e informações do padrão HTTP e também os dados necessários
para execução do serviço;
4
URL - Universal Research Location: padrão de sintaxe para identificar os documentos que são
possíveis de ser recuperados da rede mundial de computadores (W3 ou a Internet) http://en.wikipedia.org/wiki/URL.
5) O servidor aceita a conexão do cliente, interpreta os comandos HTTP, que
contém dados sobre qual serviço esta sendo solicitado, e faz a leitura da
informação específica para a execução do serviço, e caso o serviço exista no
servidor e esteja rodando normalmente, a execução do serviço é então
realizada;
6) O servidor monta o pacote de comandos HTTP de resposta, contendo o código
de status, informações de cabeçalho e também os dados inerentes à resposta
do Web Service, e envia estes pela mesma comunicação que foi antes
estabelecida.
7) O cliente processa a resposta do Web Service.
Deve-se deixar claro que o protocolo HTTP é mais completo e apresenta mais
funcionalidades àquelas foram apresentado neste tópico. Mas tratando-se da
relação do uso do protocolo HTTP pelo padrão Web Service, as características aqui
apresentadas fazem-se suficientes para dar suporte ao entendimento da tecnologia
tema deste trabalho.
4.2. XML – Extensible Markup Language
Para melhor compreender a arquitetura da tecnologia Web Services, é muito
importante um estudo básico sobre XML, pois este é responsável por formatar todos
os padrões de troca de mensagens da tecnologia Web Service.
XML é a sigla para Extensible Markup Language. Trata-se de um formato texto
simples, muito flexível, derivado do SGML (ISSO 8879). Originalmente, fora
desenhado para atender os desafios de uma publicação eletrônica em larga escala.
XML é também atualmente é uma base importantíssima para a troca de uma
variedade de dados na Web e em muito outros ambientes.
A figura 3 ilustra um exemplo de um documento XML.
Figura 3: Exemplo de documento XML
O XML tem uma estrutura bastante simples, que é baseada em hierarquia,
definida por nós. Cada nó possui atributos, e cada nó pode ainda conter outros nós,
que terão outros atributos e assim por diante.
É importante para um documento XML que ele esteja bem formatado, ou seja,
não pode haver nós sem seus respectivos terminadores, bem como não pode haver
propriedades sem a terminação com “ (aspas). Caso um documento XML não esteja
bem formatado, ele não poderá ser interpretado, ou seja, determinada software de
leitura de XML não conseguirá entender sua estrutura e obter a informação ali
contida. Na maioria das vezes, os interpretadores XML acusam erros em
determinado documento antes mesmo de fazer sua leitura por completo.
Devido a sua simplicidade e facilidade, o XML cresceu rápido, e tornou-se
ferramenta essencial em uma serie de aplicações, como por exemplo:
-
atuar como padrão de mensagens para transferência de dados entre diferentes
plataformas. Podemos citar o Web Services, XML RPC e aplicativos EDI 5.
Com seu formato texto é fortemente autodescritivo, basta desenvolver API de
interpretação de XML para cada plataforma existente, e assim, o XML passa
transparentemente entre plataformas e canais de comunicação;
-
atuar como repositório de configuração: a maioria dos softwares mais
modernos, e até os softwares proprietários de empresas independentes de
software, têm adotado o XML como o padrão para manutenção das
configurações de seus softwares, devido ao fato de XML poder ser estendido
de acordo com a necessidade de determinada aplicação por possuir atributos
e nós para identificar de maneira livre cada característica de sua
funcionalidade;
-
armazenamento de dados: apesar de não ser a melhor tecnologia para isto,
devido ao tamanho excessivo de caracteres não inerentes aos dados, o que
causa grande volume de armazenamento físico, arquivos XML podem também
ser utilizados para armazenamento de dados.
5
Electronic Data Interchange (EDI). É troca estruturada de informação entre computadores, através de
padrões estabelecidos de mensagens, de uma aplicação de computador para outra aplicação de
computador com um mínimo de intervenção humana.
Wikipedia: http://en.wikipedia.org/wiki/Electronic_Data_Interchange.
As principais fraquezas do XML são, sem dúvidas, o excessivo consumo de
banda de rede que se faz necessário para transmitir os dados dos documentos, uma
vez que estão em formatos texto, e a linguagem XML exige uma quantidade extra de
caracteres controladores da estrutura, o que deixa o documento com um tamanho em
bytes maior ainda. A segunda dificuldade é a maior necessidade por processamento
para leitura e escrita de documentos XML. Os XML Parsers, que são os programas ou
bibliotecas necessárias para trabalhar com documentos XML, possuem algoritmos
muito bem elaborados para minimizar este maior consumo, mas ainda sim, registram
índices de consumo de processamento superiores aos programas que processam
dados em forma binária.
XML Namespaces
Com a visibilidade futura de aplicações XML onde um único documento pode
conter elementos e atributos que são definidos para serem usados por múltiplos
softwares, foram criados os Namespaces.
Um XML Namespace é uma coleção de nomes, identificados por uma referência
URI, que é usada em documentos XML como tipos e elementos e atributo de nomes.
XML Namespaces provêem um método de evitar conflitos de elementos em
documentos XML. Desde que nomes de elementos em XML não são fixados, muito
freqüentemente um nome irá conflitar com outro ocorrendo dois tipos diferentes de
documentos usando a mesma descrição de nomes para dois tipos diferentes de
elementos.
Este documento XML carrega informação sobre um formulário:
<?xml version="1.0" encoding="utf-8"?>
<form>
<select>
<option>Apples</option >
<option>Bananas</option >
</select>
</form>
Este documento XML também carrega informação sobre um formulário:
<?xml version="1.0" encoding="utf-8"?>
<form>
<paper>A4</paper>
<pages>10</pages>
<name>Election Results</name>
</form>
Nos casos acima gerará conflito, pois os dois documentos contêm o mesmo
elemento <form>, mas com significados diferentes.
Para resolver o problema exposto acima o XML usa um prefixo, um exemplo de
documento XML usando prefixo:
<?xml version="1.0" encoding="utf-8"?>
<f:form>
<select>
<option>Apples</option >
<option>Bananas</option >
</select>
</f:form>
<p:form>
<paper>A4</paper>
<pages>10</pages>
<name>Election Results</name>
</p:form>
Agora os documentos não se conflitam, pois usam diferentes elementos.
4.3 SOAP – Simple Object Access Protocol
SOAP (Simple Object Access Protocol) é uma especificação com o objetivo de
possibilitar a comunicação entre dois aplicativos, de maneira descentralizada, utilizando
o XML como protocolo base, e adotando regras simples e leves. O conteúdo SOAP
precisa transmitido por um canal de comunicação, como por exemplo, uma conexão
utilizando o protocolo HTTP ou mesmo via sockets através de RPC. Outra
característica diferencial do SOAP é a de prover a integração entre plataformas
heterogêneas de software, uma vez que detalhes inerentes à arquitetura de execução
de cada plataforma são omitidos quando os dados são convertidos para XML.
Vale ressaltar que o SOAP não foi desenvolvido especificamente para uso exclusivo
na tecnologia Web Services. O protocolo de mensagens SOAP pode também ser
empregado como padrão em outras arquiteturas de softwares distribuídos, ou mesmo
em implementações proprietárias de empresas de software. Isto garante o amplo uso
de SOAP e sua independência de qualquer modelo particular ou arquitetura específica.
As maiores dificuldades do padrão SOAP residem exatamente no problema de
utilização do XML: tamanho dos documentos é muito grande, o que ocasiona consumo
de banda, e o processamento dos arquivos XML utiliza mais recursos de
processamento das estações, o que evidencia que padrão SOAP não é recomendado
para uso interno em uma empresa, pois existem tecnologias distribuídas mais
eficientes, como por exemplo, o CORBA ou DCOM.
De acordo com a especificação no W3C para o SOAP [4], este é constituído por três
partes:
-
um envelope que define uma base para descrever o que está na mensagem e
como processá-la;
-
um conjunto de regras para expressar tipos de dados de instâncias definidas a
nível de aplicativo;
-
e uma convenção para representar chamadas e respostas de procedimentos
remotos.
Ainda de acordo com o W3C, apesar da possibilidade de utilizar-se SOAP em uma
variedade não definida de canais de comunicação, a entidade definiu que sua
especificação é fortemente voltada a implementação de uma comunicação com SOAP
através de HTTP. Portanto, este trabalho de pesquisa está voltado para este cenário.
4.3.1 Exemplos de mensagens SOAP
4.3.1.1 Envio de uma solicitação de execução de um Web Service
No exemplo a seguir, é mostrado um trecho de XML que corresponde a
chamada de um Web Service. Portanto, o canal de comunicação utilizado é o HTTP e a
mensagem é codificada utilizando-se SOAP versão 1.1. O Web Service em questão é
representado
pelo
arquivo
“Service.asmx”,
e
contém
o
método
“RetornarCotacaoDolarNoDia”, que quando executado, retorna a cotação do dólar.
1: POST /WebSite1/Service.asmx HTTP/1.1
2: Host: localhost
3: Content-Type: text/xml; charset=utf-8
4: Content-Length: length
5: SOAPAction: "http://tempuri.org/RetornarCotacaoDolarNoDia"
6:
7: <?xml version="1.0" encoding="utf-8"?>
8: <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
9: xmlns:xsd="http://www.w3.org/2001/XMLSchema"
10: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
11: <soap:Body>
12:
<RetornarCotacaoDolarNoDia xmlns="http://tempuri.org/" />
13: </soap:Body>
14: </soap:Envelope>
Em síntese, este trecho representa um comando HTTP, que se utiliza o método
POST, conforme pode ser observado na linha (1), disparando para o Web Service
localizado no endereço “/WebSite/Service.asmx”, localizado no servidor onde foi
estabelecida a conexão HTTP. As linhas (2),(3),(4),(5) representam o cabeçalho HTTP.
Logo após os comandos HTTP, temos a mensagem SOAP. Observe a entidade
<soap:Envelope>. Ela representa o envelope, o nível máximo da estrutura XML do
SOAP.
Em seguida, aparece o <soap:Body>, que é o corpo da mensagem SOAP. Este
elemento XML provê um mecanismo simples para a troca da informação obrigatória
para a execução do serviço Web. Tipicamente, o <soap:Body> pode transmitir as
informações necessárias para a execução dos serviços ou mesmo informações sobre
erros acontecidos durante seu processamento. No caso apresentado, o <soap:Body>
contém informações para executar o método “RetornarCotacaoDolarNoDia” que está
no
serviço
web
requisitado
(“Service.asmx”).
Caso
o
método
“RetornarCotacaoDolarNoDia” possuir mais detalhes para execução, como por
exemplo, o envio de parâmetros para execução da rotina, estes devem ser informados
dentro do elemento “RetornarCotacaoDolarNoDia”.
4.3.1.2 Resposta de uma solicitação de execução de um Web Service
A partir do exemplo anterior, onde foi invocado um Web Service que devolve ao
solicitante a cotação do dólar no dia, segue a reprodução da mensagem de resposta
produzida pela execução do Web Service.
1: HTTP/1.1 200 OK
2: Content-Type: text/xml; charset=utf-8
3: Content-Length: length
4:
5: <?xml version="1.0" encoding="utf-8"?>
6: <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
7: xmlns:xsd="http://www.w3.org/2001/XMLSchema"
8: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
9: <soap:Body>
10:
<RetornarCotacaoDolarNoDiaResponse xmlns="http://tempuri.org/">
11:
<RetornarCotacaoDolarNoDiaResult>12</RetornarCotacaoDolarNoDiaResult>
12:
</RetornarCotacaoDolarNoDiaResponse>
13: </soap:Body>
14: </soap:Envelope>
Novamente, a primeira parte da resposta compreende os códigos específicos do
protocolo HTTP. A primeira linha define o código de status, que no caso é 200,
informando que o serviço procurado pelo POST (“/WebSite1/Service.asmx”), no
momento da requisição, foi encontrado e processado. As duas linhas seguintes
representam as informações de cabeçalho HTTP.
Na mensagem SOAP recebida, observamos novamente a presença obrigatório
do envelope SOAP, representado pelo elemento <soap:Envelope>, e também do
elemento <soap:Body>. Dentro deste, encontra-se em detalhes a resposta enviada
pelo serviço Web. No caso do nosso serviço “RetornarCotacaoDolarNoDia”, que
retorna
um
número,
vemos
o
mesmo
dentro
do
elemento
<RetornarCotacaoDolarNoDiaResponse>.
Os exemplos de mensagens SOAP apresentados e explicados neste capítulo
são o que em essência forma um Web Service: uma chamada HTTP, contendo um
conjunto de instruções em XML, contra um objeto web, e a resposta deste
procedimento, também através de instruções em XML. É um funcionamento simples,
mas muito eficiente para tornar possível que funcionalidades distribuídas comuniquemse e executem em ambientes de software heterogêneos.
4.4 WSDL – Web Service Description Language
Como a comunicação e troca de mensagens no ambiente Web é padronizada,
tornou-se conseqüência a necessidade de existir a possibilidade de descrever estes
padrões de forma estruturada. O padrão WSDL – Web Service Description
Language foi desenvolvido para atender esta necessidade. No caso de Web
Services, um Web Service é sempre descrito programaticamente utilizando a
sintaxe definida pelo padrão WSDL.
De acordo com a definição do W3C, “WSDL é um formato XML que descreve
serviços de rede com um conjunto de endpoints (pontos finais) operando em
mensagens contendo informações orientadas a documento ou informações
orientadas a procedimentos. As mensagens são descritas de maneira abstrata, e
depois são convertidas para a rede real de protocolos e mensagens que definem o
endpoint.”.
Desta maneira, entende-se que o WSDL define um serviço de rede de maneira
abstrata, ou seja: as características de execução do serviço, como meios de
transmissão, linguagem de programação e tipos de dados utilizados, não estão
representadas de modo que as relacionem somente a uma arquitetura, mas estão
descritas de forma que seja possível a qualquer arquitetura implementar ou utilizar
um serviço descrito através de um documento WSDL.
É uma tarefa complicada tentar descrever um serviço em um nível tão abstrato,
não importando, por exemplo, o protocolo de comunicação ou a plataforma que
hospeda o serviço. É consenso comum que dependendo da plataforma de
execução, até os tipos de dados podem diferentes e incompatíveis com outras
plataformas, o que torna impossível a execução de determinado serviço.
Mas o WSDL resolve esta problemática porque ele força a utilização de padrões
comuns nas arquiteturas, para justamente garantir a execução dos serviços. E por
permitir montagens específicas, ou seja, por ser extensível, o WSDL pode
futuramente atender a novas necessidades sem precisar ser revisto em sua
especificação inicial.
Mas apesar de ter a capacidade de representar qualquer serviço distribuído de
rede, o WSDL foi concebido pelo W3C com o objetivo de atender a plataforma Web
Services. Portanto, todos os exemplos de especificação e implementações
realizadas até agora podem ser vistos mais comumente em arquiteturas que
empregam Web Services.
4.4.1 Estruturas do WSDL
O WSDL utiliza os seguintes elementos na definição de serviços de rede:
Figura 4: Esquema básico de uma descrição de um Web Service
Types: um agrupador para definições de tipos de dados usando alguns tipos de
dados de sistemas.
Message: uma definição abstrata do tipo de dado que será comunicado.
Operation: uma descrição abstrata de uma ação suportada pelo serviço.
Port Type: um conjunto abstrato de operações suportadas por um ou mais
endpoints.
Port: um único endpoint definido como uma combinação de um binding e um
endereço de rede.
Service: uma coleção de endpoints relacionados.
Exemplo completo de um documento WSDL
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
4.5 - UDDI - Universal Description, Discovery and Integration
Uma arquitetura SOA baseada em Web Service pode usufruir-se da capacidade
de publicação determinado serviço em uma rede IP. Esta rede pode ser pública,
como Internet, ou privada, dentro de uma empresa. Este registro é padronizado, e
chamado de UDDI (Universal Description, Discovery and Integration), e também
pode ser público ou privado. Com o UDDI, as empresas que oferecem Web
Services podem publicar seus serviços em listas, podem unir-se umas as outras, e
por diante, definindo uma nova maneira sobre como os serviços ou aplicações de
software interagem-se na Internet.
UDDI consiste [7] em um esquema XML que define quatro estruturas de dados:
- Registro do negócio, que é um esquema XML para descrever os negócios e
Web Services;
- A definição dos serviços;
- A descrição sobre como encontrar e conectar automaticamente à suas
funcionalidades dos serviços;
- E uma interface programática que define uma API que opera nestas estruturas.
Esta interface é baseada em SOAP.
Por sua vez, o registro do negócio em um UDDI é formado por três
componentes:
- White Pages: contém informações sobre uma empresa especifica, como por
exemplo, nome, endereço, contatos e localização.
- Yellow Pages: contém dados para classificação geral de qualquer empresa ou
serviço oferecido, como por exemplo, tipo da indústria, de produtos ou códigos
geográficos.
- Green Pages: contém informações técnicas sobre os serviços expostos por
determinado UDDI, como por exemplo, qual a URL para acessar determinado
serviço.
Figura 5: Fluxo de informação do UDDI
A figura 5 mostra o exemplo de um fluxo descobrimento e descrição de
determinado Web Service. O Web Service Provider, que é o responsável por criar e
garantir com que o Web Service fique disponível para utilização, realiza a operação
de publicação (representado pelo traço (P)) do serviço no diretório UDDI. Um Web
Service Requester realiza a operação de busca por um serviço, representando o
passo número (1). Em seguida, as operações (2) e (3) representam a troca de
mensagens entre o Web Service Requester e o Web Service Provider quanto a
definições do Web Service, utilizando nesta troca de dados o padrão WSDL.
De acordo com a W3C 6, o padrão UDDI foi escrito em Agosto de 2000, em torno
da idéia de que o UDDI tornaria possível que qualquer tipo de serviço fosse
disponibilizado na Internet, e pudesse ser utilizado por qualquer outro serviço ou
programa de software. Mas a realidade é que determinado serviço pode ser critico
para determinado indivíduo que esteja precisando deste. Portanto, os interesses
comerciais falaram mais altos, e o alcance dos registros UDDI foi bem limitado, e
atualmente, o cenário mais ideal no qual pode-se empregar o UDDI é dentro de
uma mesma empresa, onde se cria repositórios UDDI para que as aplicações
6
Wikipedia, enciclopédia pública da Internet.
http://en.wikipedia.org/wiki/Main_Page
clientes possam automaticamente conectar-se as implementações de serviços ou
negócios da companhia.
4.5.1 O UDDI Business Registry (UBR)
De acordo com o UDDI.org 7, O UDDI Business Registry é um registro UDDI
público e gratuito, atualmente operado e mantido através de uma joint venture que
conta com o suporte da IBM, Microsoft, SAP e NTT Comunications. Qualquer indivíduo
é livre para publicar informações sobre seus Web Services públicos em qualquer um
dos nós do UBR.
O objetivo do UBR é facilitar a publicação dos Web Services públicos. Um
indivíduo que cadastra seus serviços num nó da UBR, não precisa fazer em outro nó,
uma vez que os sites UBR comunicam-se entre si, promovendo a replicação contínua
entre seus dados, fazendo assim com que a operação de descobrimento de
determinado Web Service, através do padrão UDDI, seja a mais rápida possível. A
atualização dos registros não é diária, mas mesmo assim é um mecanismo de grande
abrangência e eficiência.
7
UDDI.org: Entidade que promove a tecnologia Web Services. http://www.uddi.org/faqs.html
5. SOA e Web Services no ambiente de negócios
Os grandes avanços realizados pela tecnologia Web Services aconteceram, sem
dúvida alguma, devido aos esforços conjuntos de grandes empresas de software, como
Microsoft, IBM, Sun, W3C, e outras. Graças aos diversos profissionais destas
empresas, que se encarregaram de definir os padrões e escrever todas as
especificações da tecnologia Web Services, hoje os desenvolvedores podem utilizar
com segurança e confiabilidade uma tecnologia que está muito difundida na Internet,
apresentando uma grande variedade de material para pesquisa, suporte técnico e
softwares para desenvolvimento.
Apesar de todo o trabalho executado, uma implementação prática de uma
arquitetura orientada a serviços (SOA), precisa de uma certa estratégia para que seu
sucesso seja atingido plenamente.
Scott Simmons 8, da equipe do WebSphere 9, cita [6], em Setembro de 2006,
que são diversos fatores necessários para o sucesso da implementação de uma
arquitetura de software orientada a serviços, mas o que realmente ele observou
durante sua carreira é que as empresas que obtiveram êxito tinham todas em comum o
fato de terem desenvolvido um plano de Governança de TI para suportar o design,
desenvolvimento, publicação e operacionalização de um framework de software
baseado em SOA. Sem um plano de governança para dar suporte à implementação da
arquitetura SOA, as chances de um projeto ser mal-sucedido são muito maiores.
Ainda de acordo com Simmons, uma arquitetura SOA muda a missão do
departamento de TI e o relacionamento do TI com o resto da organização.
8
Arquiteto-executivo para do time para Integração Mundial dos Serviços de Suporte Técnico.
WebSphere: Nome comercial de produto. É o mundialmente conhecido servidor de aplicações de
software da IBM.
9
Além do projeto de Governança de TI, os esforços para obter o sucesso na
implementação de uma arquitetura SOA possuem quatro núcleos principais:
- a definição e o reforço de policiamento e de procedimentos para suportar o
design, desenvolvimento, publicação e gerenciamento de serviços com um
conjunto correspondente de métodos, técnicas e ferramentas para dar suporte
ao SOA e a requerimentos táticos e estratégicos do négocio;
-
o estabelecimento de um Centro de Competência (ou Centro de Excelência),
representando tanto o departamento de Tecnologia da Informação e demais
departamentos da empresa para manter e avançar as iniciativas SOA como
uma competência compartilhada através da organização;
-
apoio e patrocínio dos executivos da empresa para com as intenções e
objetivos do SOA, realizando mandatos para dar o contínuo suporte à
comunicação entre os responsáveis pelo desenvolvimento, implementação e
gerenciamento do SOA;
-
um entendimento ao nível organizacional para taticamente executar e
estrategicamente planejar a adoção do SOA. O SOA é incremental e uma
evolução que muda desde o departamento de TI até a organização por
completo, e é beneficiado por uma implementação interativa entre as áreas.
5.1 Benefícios
De fato, uma implementação de uma arquitetura orientada a serviços, que utiliza
o Web Services como tecnologia central, não precisa do desenvolvimento de um novo
ambiente de execução por completo, pois as ferramentas hoje existentes para o Web
Services permitem rodar em ambiente já existe, e possibilitar aos Web Services que
são criados que estes se tornem ser parte integrante do legado do software já existente
em uma companhia.
Após o desenvolvimento de um bem-sucedido plano de Governança de TI que
englobe a iniciativa Web Services, uma organização que consegue colocar em prática
a arquitetura obtém benefícios imediatos como: a flexibilização em um novo tipo de
design de software; a reutilização de componentes de negócio já existentes em novas
redes; e a possibilidade de interoperabilidade e integração com plataformas antigas,
novas, ou diferentes (implementação de arquitetura, ex: Windows x Linux).
O tempo de desenvolvimento de uma rotina é reduzido pela implementação de
um Web Service. O processo de um Web Services, desde sua concepção e publicação,
de um modo geral tem tempo curto de duração, o que permite que os processos das
empresas respondam de maneira mais rápida e positiva às mudanças do mercado.
Outras características benéficas de um Web Service ficam mais claras quando
são analisados os ganhos que este trouxe aos negócios que foram afetados por ele.
Por exemplo: uma empresa que deseje obter cotações de compras de seus
fornecedores de uma maneira mais eficiente utilizando um Web Service de Cotações
on-line, conectando os fornecedores ao seu software de compras interno, via Internet,
terá a possibilidade de conseguir cotações mais rapidamente, e conseqüentemente,
poder trabalhar melhor com as propostas de preços oferecidas, reduzindo os custos de
aquisição de determinado produto.
Empresa Compradora
Fornecedor A
Servidor Web
Armazena e
processa o
Web Service
Cotação on-line
Fornecedor B
Fornecedor C
SOAP
sobre HTTP
Departamento
Compras
Banco de Dados da
Empresa Compradora
Figura 6: Esquema de sistema de cotação on-line
Para o fornecedor, a utilização do Web Service de cotação on-line é a garantia
de que sua cotação está entregue diretamente ao sistema de compras de seu cliente, e
que a resposta se sua oferta é a melhor será a mais rápida possível, uma vez que
possivelmente não haverá intervenção humana neste cenário.
5.2 Limitações e aspectos críticos
Uma arquitetura orientada a serviço utilizando Web Services não é a solução
para todos os desafios de integração e interoperabilidade existentes hoje para o setor
de Tecnologia da Informação.
Seguem pontos onde uma arquitetura distribuída pode não ser um beneficio e
alguns aspectos críticos:
- um modelo orientado a serviços talvez não é o melhor para rodar rotinas de
negócio complicadas e demoradas em modo assíncrono. O processo natural
de um ambiente orientado a serviço é o envio de uma mensagem, seu
processamento rápido e a devolução da resposta. Uma utilização diferente
disto pode ocasionar problemas aos quais a especificação de tecnologias SOA
não oferecem uma cobertura suficiente;
- SOA requer um framework de ambiente que em muitos casos são softwares
em “estado-de-arte”, como a plataforma Microsoft.NET, o NetWeaver da SAP e
WebSphere da IBM, e infelizmente, apesar dos esforços, não há nada que
garanta uma interoperabilidade completa entre estas plataformas;
- existe uma certa dificuldade em garantir a qualidade das mensagens que são
transmitidas em um ambiente de software distruibuido. No caso de Web
Services, que utiliza como canal de transporte o HTTP, este fica suscetível a
uma infinidade de riscos, como por exemplo: problemas na conexão de rede,
problemas com servidores DNS (no momento de conectar-se a um Web
Service), e muitos outros. São problemas que não podem ser controlados ou
totalmente catalogados e controlados por um Web Service, pois ocorrem em
partes externas que não são acessíveis por ele.
6. Conclusão
Através da utilização de diversas tecnologias abertas como base para sua
existência, o Web Services rapidamente ganhou espaço no mercado, e tem sido o
melhor quando o assunto é software distruibuido (ou SOA). Ela é flexível e permite o
funcionamento de sistemas em uma linguagem abstrata de nível acima de muitos
outros padrões, o que garante o Web Services como uma das melhores tecnologias
para realizar a comunicação entre plataformas heterogêneas de software.
Devido à limitação do tempo para o desenvolvimento deste trabalho, não foi
possível estendê-lo a outros detalhes inerentes a tecnologia, como por exemplo, a
questão da segurança dos dados e também quais os softwares existentes na
atualidade que garantem o funcionamento de um ambiente para o Web Services. Fica
o desejo de que numa próxima oportunidade seja possível estudar e apresentar estes e
outros itens.
Apesar dos pontos críticos ou até falhos desta tecnologia, como a limitação para
rodar processos assíncronos ou demorados e o custo da transmissão dos dados
devido ao tamanho das mensagens XML, ainda existem muitos outros fatores positivos
que a tornam promissora, como o uso de tecnologias abertas, o conceito de abstração,
para permitir a interoperabilidade entre plataformas, e vantagem que ela oferece de
agregar valor ao negócio de uma empresa, pois o Web Service não vem substituir
sistemas e softwares existentes, e sim para tornar sistemas já existentes compatíveis
uns com os outros, possibilitando à empresa ser mais rápida em suas respostas às
mudanças do mercado.
Web Services tem tudo para ser um “divisor de águas” como foi quando
apareceram as primeiras arquiteturas em três camadas, que acabaram com o modelo
cliente / servidor. O futuro promete aplicações mais voltadas a serviços, permitindo a
empresa comunicar-se com o ambiente externo, de forma programática e sem
necessidades maiores de intervenções pelos desenvolvedores. Espera-se agora, que
continue o suporte desta tecnologia pelos grandes fabricantes de software, e o
principal, que esforços para manter um padrão único continuem existindo e
regulamentando esta tecnologia.
7. Bibliografia
7.1 Bibliografia Básica
[1] IBM - Definição de SOA:
http://www-128.ibm.com/developerworks/webservices/newto/
[2] W3C - Definição de Web Services: http://www.w3.org/2002/ws/Activity
[3] W3C - Especificação do WSDL: http://www.w3.org/TR/wsdl
[4] W3C – Especificação SOAP: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[5] W3C – Especificação Web Services: http://www.w3.org/TR/2000/NOTE-SOAP20000508/
[6] IBM – SOA governance and the prevention of service-oriented anarchy
http://www128.ibm.com/developerworks/websphere/techjournal/0609_col_simmons/0609_col_sim
mons.html?ca=drs[7] Wikipedia – Definição de UDDI
http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
7.2 Bibliografia Auxiliar
KREGER, H.
eBook – Web Services Conceptual Architeture (WSCA 1.0)
IBM. 2001
WIEHLER, G.
eBook - Computer - Service Oriented Architecture
Siemens. 2004.
VIII