SOAP (Simple Object Access Protocol: em portugus Protocolo

Simples de Acesso a Objetos) um protocolo para troca de informaes

estruturadas em uma plataforma descentralizada e distribuda. Ele se baseia
na Linguagem de Marcao Extensvel (XML) para seu formato de
mensagem, e normalmente baseia-se em outros protocolos da camada de
aplicao, mais notavelmente em chamada de procedimento remoto (RPC)
e Protocolo de transferncia de hipertexto(HTTP), para negociao e
transmisso de mensagens. SOAP pode formar a camada base de uma pilha
de protocolos de servios Web, fornecendo um arcabouo bsico de
mensagens sob o qual se podem construir os servios Web. Aplicando este
padro em Web Services, geralmente usa-se o WSDL para descrever a estrutura
das mensagens SOAP e as aes possveis em um endpoint.

Uma das maiores vantagens disso que vrias linguagens e ferramentas

conseguem ler e gerar mensagens facilmente. Vrias linguagens de programao
permitem a gerao de objetos de domnio, Stubs e Skeletons a partir da definio
do WSDL, permitindo a comunicao remota via RPC atravs de chamadas a
mtodos remotod, inclusive com argumentos complexos, como se fossem
chamadas locais.
O problema desse padro, que ele adiciona um overhead considervel, tanto por
ser em XML quanto por adicionar muitas tags de meta-informao. Alm disso, a
serializao e desserializao das mensagens pode consumir um tempo
considervel.

REST
REST outro um protocolo de comunicao, baseado no protocolo de hipermdia
HTTP. Porm ele no impe restries ao formato da mensagem, apenas no
comportamento dos componentes envolvidos.
A maior vantagem do protocolo REST sua flexibilidade. O desenvolvedor pode
optar pelo formato mais adequado para as mensagens do sistema de acordo com
sua necessidade especfica. Os formais mais comuns so Json, XML e texto puro,
mas em teoria qualquer formato pode ser usado.
Isso nos leva a outra vantagem: quase sempre Web Services que usam REST so
mais "leves" e, portanto, mais rpidos.
O problema com o REST pode surgir justamente por causa de suas vantagens.
Como a definio do corpo de dados fica totalmente a cargo do desenvolvedor, os
problemas de interoperabilidade so mais comuns.

WSDL um a descrio em formato XML de um Web Service que utilizar SOAP /

RPC como protocolo. o acrnimo de Web Services Description Language
(Linguagem de Descrio de Servios Web).
RPC Remote Procedure Calls (em portugus, chamada de procedimentos
remotos) um modelo que define a forma como so realizadas as chamadas a
operaes remotas atravs de web services.
Por meio de um WSDL voc informa ao cliente como cada servio em um endpoint deve ser invocado: quais os parmetros e tipo de dados de cada parmetro
esperado, e qual o tipo de dado do retorno ser enviado como resposta.
Alm de descrever cada servio (que pode ser comparado analogamente um
mtodo a ser executado no programa servidor), tambm descreve como podem ser
encontrados.
WSDL utilizado diretamente com SOAP, quando um cliente realiza uma chamada
de servio por meio de SOAP, primeiramente ele solicita o WSDL para entender
como se dar esta negociao.
REST trabalha sobre o protocolo HTTP puro, portanto no depende do protocolo
SOAP para realizar a comunicao, em consequncia no necessita usar uma
WSDL. Apenas os verbos HTTP so utilizados. Neste caso, para um cliente
solicitar servios REST, ele necessita de antemo conhecer o caminho e interface
deles. Siginifica dizer que o desenvolvedor precisar de manual ou guia de
programao para usar uma API REST.

UDDI (originado do acrnimo ingls Universal Description, Discovery and

Integration) um servio de diretrio onde empresas podem registrar
(publicar) e buscar (descobrir) por servios Web (Web Services). UDDI
ainda um framework de plataforma independente (desenvolvido na
plataforma .NET) para descrever e integrar os servios de negcios usando
a internet, possibilitando assim uma exposio controlada dos servios da
empresa. A comunicao realizada atravs do SOAP e as interfaces web
service so descritas por WSDL.[1]
Um servio de registro UDDI um Web Service que gerencia informao
sobre provedores, implementaes e metadados de servios. Provedores de
servios podem utilizar UDDI para publicar os servios que eles oferecem.
Usurios de servios podem usar UDDI para descobrir servios que lhes
interessem e obter os metadados necessrios para utilizar esses servios
podem ter trs partes:

"pginas brancas"
contatos, etc.

descrevem

companhia:

nome,

endereo,

"pginas amarelas" incluem as categorias, baseada em taxonomias

padres.

"pginas verdes" descrevem a interface para o servio em nvel de

detalhe suficiente para se escrever uma aplicao que use o Web
service.

SOA um conceito de arquitetura corporativa que promove a integrao

entre o negcio e a TI por meio de um conjunto de interfaces de servios
acoplados. Um dos componentes mais importantes em SOA prov uma
camada de abstrao que permite a integrao entre os aplicativos,
atuando como um intermedirio entre a implementao de um servio e
a forma como ele exposto, para que seja consumido. Este componente
conhecido como. ESB

ESB

- Enterprise

Service

Bus se

refere

arquitetura de

construo

de software tipicamente implementado em tecnologias encontradas na categoria de

produtos de infraestrutura de middleware.
Normalmente baseado no reconhecimento de padres, que fornecem uma base de
servios para arquiteturas mais complexas via um driver de evento e padres baseados
em mensagens (BUS).
Um ESB geralmente fornece uma abstrao de camadas na implementao de um
sistema empresarial de mensagens, que permita integrao da arquitetura para explorar o
valor das mensagens sem escrever cdigo. Contrariando a clssica integrao de
aplicaes comerciais (EAI). A base de um enterprise service bus construda da quebra
de funes bsicas em partes, que so distribudas onde for preciso.
ESB no implementa uma arquitetura orientada a servio (SOA), mas fornece as
caractersticas para que possa ser implementado. ESB no necessariamente precisa ser
implementado usando web services. ESB devem ser baseados em padres flexveis,
suportando vrios meios de transporte. Baseado no EAI melhor que padres SOA, ele
tenta remover o acoplamento entre o servio chamado e o meio de transporte.
A maioria dos fornecedores de ESB constroem agora ESBs para incorporar princpios de
SOA e para aumentar suas vendas, por exemplo Business Process Execution
Language(BPEL).

I.

Novos servios podem ser criados a partir da composio de

servios existentes. Verdadeiro

II.

Os agentes consumidores podem acessar os servios sem

conhecer detalhes de sua implementao. Verdadeiro

III.

um estilo de arquitetura que estabelece uma forte relao de

dependncia entre os servios disponveis. Falso, "SOA ajuda a TI
a pensar as solues de tecnologia de forma integrada, mas com
baixo acoplamento (sistemas com pouca dependncia de outras
funes e aplicaes)".

IV.

Os servios tendem a oferecer um nmero grande de operaes

com complexidade relativamente pequena em cada uma delas.
Falso, "servios tendem a usar um nmero pequeno de operaes
com uma complexidade relativamente grande nas operaes
realizadas."

V.

Para que as funcionalidades da aplicao estejam de acordo

com o paradigma SOA deve-se Implementar as funcionalidades
do sistema na forma de servios, garantindo que estes
mantenham um baixo acoplamento, uma alta coeso e sejam de
uma granularidade grossa.

VI.

As mensagens so o principal meio de comunicao entre os

provedores e os consumidores de servios.

VII.

SOA no prescreve como projetar ou construir a implementao

do servio.

VIII.

Quando os servios so disponibilizados na web, eles so

identificados por uma URI.

Atravs deste trabalho foi possvel identificar algumas caractersticas

relevantes que todas aplicaes e frameworks que se dizem orientados a
servios possuem. importante ressaltar que no necessrio que se tenha
todas caractersticas listadas a seguir para denominar se uma aplicao
orientada a servios; pelo contrrio, a maioria das aplicaes estudadas
possui apenas um pequeno subconjunto dessas caractersticas, e so
autoproclamadas como aplicaes orientadas a servios. As caractersticas
consideradas
relevantes
so:
-

Reuso Caixa-preta
Distribuio
Heterogeneidade Ambiental
Composio
Coordenao
Dinamismo e Adaptabilidade
Estado
Sincronia No entra Assncronia
Robustez de Protocolos