Padrões da Arquitetura Orientada à servicos – SOA

A arquitetura SOA possui dois tipos de modelos de webservices, sendo um de primeira

geração e de segunda geração, exemplificado abaixo.

Figura – Primeira geração de webservices

Figura - Segunda geração de webservices
A Arquitetura Orientada a Serviços envolve três aspectos principais:

• A localização de serviços: Incluindo a procura por serviços que satisfaçam

determinados critérios de negócio;

• A organização de serviços: de forma que um requisitante de serviços possa

compreender facilmente o que um serviço oferece;

• A especificação de serviços: incluindo os protocolos para que os serviços possam ser

invocados de modo apropriado.
 2.1.1 Web Services Description Language -WSDL

Segundo W3C (2005), um documento WSDL descreve os serviços da Web

Service através do XML, fornecendo uma documentação do serviço para possíveis
clientes que possam utilizá-lo. Com isso, o documento oferece uma estrutura que
organiza seus elementos de forma complexa e padronizada.
Um documento WSDL define serviços como uma coleção de pontos de acesso
de rede, ou uma porta. Porta é definida como uma associação entre um endereço de rede
re-usável, e uma coleção de portas define um serviço (OLIVEIRA, 2007).
 De acordo com Amorim (2004), a estrutura de um documento WSDL (Figura 4)
contém elementos que formam a estruturação de um serviço. Este documento contém a
seguinte estrutura:

Figura 4 - Estrutura do documento WSDL (W3C, 2005) com adaptações.

Os elementos de um WSDL apresentados na figura 4 são descritos da seguinte

forma:
• Tipo de Porta (PortType): O elemento PortType contém um conjunto de
operações representadas como elementos operation que possui um
atributo name e um outro atributo opcional que especifica a ordem dos
parâmetros usados nas operações que estão presentes em web service.
Além disso, ele pode ter apenas uma mensagem de entrada e uma
mensagem de saída, da mesma forma que de uma chamada de método
normal.
• Mensagem (Message): O elemento message contém uma definição dos
dados a serem transmitidos. É semelhante ao parâmetro na chamada do
método.
• Tipo (Type): O elemento type contém os tipos de dados que estão
presentes na mensagem.
• Ligação (binding): O elemento binding mapeia os elementos operation
em um elemento PortType, para um protocolo específico.
• Serviço (service) e Porta (port): Os elementos service e port (contido no
service) incluem a localização da implementação do serviço na rede, ou
seja, contém a informação para onde enviar a solicitação do serviço.
 O WSDL define um mecanismo para ligação (binding) com o servidor, sendo
usado para anexar um protocolo ou um formato de dados ou uma estrutura de
mensagem simples, operação ou portas (endpoint). Desta maneira, o documento WSDL
descreve uma interface pública para um Serviço Web (OLIVEIRA, 2007).
O WSDL possui as seguintes versões:

WSDL 1.1
WSDL 2.0 Part 1 (core language)
WSDL 2.0 Part 2 (message patterns)

2.1.2 Simple Object Access Protocol – SOAP

De acordo com W3C (2005), SOAP (Simple Object Access Protocol) é um

protocolo baseado em XML para troca de informações em um ambiente distribuído. Ele
é utilizado para troca de mensagens entre aplicativos distribuídos pela rede.
SOAP é um protocolo projetado para invocar aplicações remotas através de RPC
(Remote Procedure Call) ou trocas de mensagens, em um ambiente independente de
plataforma e linguagem de programação. Portanto é um padrão normalmente aceito para
utilizar-se com web services. Desta forma, pretende-se garantir a interoperabilidade e
intercomunicação entre diferentes sistemas, através da utilização de uma linguagem
XML e mecanismo de transporte HTTP padrões (W3C, 2005).
SOAP permite o funcionamento de web services, independentemente de
linguagens de programação e plataformas utilizadas nas aplicações. Além disso, SOAP
atua na forma em que a comunicação feita entre sistemas, semelhante ou não, seja feita
de forma mais transparente principalmente se tratando de sistemas de padrões abertos
.
De acordo com o W3C (2009) a estrutura da mensagem SOAP (Figura 5) é
definida em um documento XML que contém os seguintes elementos:
• Envelope: Identifica o documento XML como uma mensagem SOAP e é
responsável por definir o conteúdo da mensagem;
• Cabeçalho (opcional): Contém os dados do cabeçalho;
• Corpo: Contém as informações de chamada e de resposta ao servidor;
• Carga Útil: Contém as informações dos erros acorridos no envio da
mensagem.
Este elemento só aparece nas mensagens de resposta do servidor.
 Figura 5 - Estrutura do Protocolo SOAP (W3C, 2005) com adaptações

Atualmente o SOAP possui as seguintes versões:

SOAP 1.1
SOAP 1.2 Part 0 (primer)
SOAP 1.2 Part 1 (messaging framework)
SOAP 1.2 Part 2 (adjuncts)
SOAP 1.2 (assertions and test collection)
SOAP Message Transmission Optimization Mechanism (MTOM)
XML-binary Optimized Packaging (XOP)

2.1.1 JAX-RPC (Java API for XML-Based RPC)

JAX-RPC (Java API for XML-Based RPC) é utilizada para gerar a

interoperabilidade de serviços web entre plataformas de linguagem heterogêneas (ver
Figura 6). Ela permite a invocação e o provimento de serviços de forma a fornecer
suporte WSDL para Java e Java para WSDL, mapeando o desenvolvimento de clientes
e endpoints (SUN, 2009).
 Figura 6 - Funcionamento do JAX-RPC (SUN, 2009) com adaptações

O JAX-RPC atua com SOAP, em conjunto com o HTTP, garantindo a

interoperabilidade, fornecendo suporte para manipular e criar extensões de SOAP,
gerando mensagem seguras.

2.2 Universal Description, Discovery and Integration - UDDI

Segundo W3C (2005), o SOAP é usado para efetuar a comunicação entre as

partes em um sistema distribuído, e WSDL descreve como essa comunicação deve ser
feita, UDDI tem a responsabilidade de fornecer um mecanismo para localização de
serviços (Service Provider). Este protocolo é utilizado para a comunicação com registro
de serviços, promovendo o acesso semelhante a uma lista telefônica, onde contém os
serviços registrados para serem oferecidos, onde os consumidores podem acessar uma
variedade de serviços.
Segundo Oasis (2006), UDDI é um repositório que compreende informações
sobre os seguintes itens principais: Provedor de serviços, especificação de serviço e
implementação de serviço.
 Os servidores UDDI foram propostos para ser um grande repositório universal
de serviços, por onde todos os clientes iriam buscar dinamicamente os serviços.
Atualmente esse modelo não é utilizado, e tipicamente os clientes não passam pelo
servidor de UDDI para acessarem os serviços requeridos, relegando os servidores de
UDDI a uma função secundária. Além disso, principalmente devido a restrições de
segurança, servidores UDDI privados estão se tornando uma tendência, onde apenas
clientes internos possuem acesso ao registro de serviços (MACHADO, 2004).

Atuamente exite as versões do protocolo UDDI:

UDDI 2.0 Specifications
 UDDI 3.0 Specifications

2.3 Business Process Execution Language - BPEL

Segundo LAU ET. AL (2009) o BPEL define uma gramática para descrever o
comportamento dos processos de negócios baseada na interação entre os processos e os
seus parceiros. A interação com cada parceiro ocorre através de interfaces de serviços
web. O processo define como as múltiplas interações com esses parceiros serão
coordenadas para realizar um determinado processo de negócio.
A composição de serviços, que promovem a execução da lógica de negócios é
denominada de orquestração (do inglês Orchestration). Uma orquestração é um
processo de negócio executável, controlado por um dos participantes do processo (LAU
ET. AL, 2009).
A orquestração descreve a interação entre serviço, no nível de troca de
mensagem, incluindo uma lógica de negócio e ordem de execução. Nesta Orquestração,
o BPEL é a linguagem que manipula o fluxo de negócios (ver Figura 7) contidos em
uma cadeia de web services.

Figura 7 - Exemplo simplificado de um processo de negócio processo (LAU ET. AL, 2009) com

adaptações
 Na linguagem BPEL cada instrução é uma atividade. As instruções são representadas no

documento por elementos XML. Atividades podem ser básicas ou estruturadas.

As atividades básicas da linguagem BPEL são:

• receive: instrução para o recebimento de uma requisição de serviço.

• invoke: instrução para envio de uma requisição de serviço.

• reply: instrução para resposta a uma requisição de serviço realizada anteriormente.

• throw: instrução utilizada para sinalizar a ocorrência de uma falha interna.

• wait: permite que um processo especifique um atraso por um certo período de tempo (for) ou até que um

prazo final (until) seja atingido.

• empty: instrução que não realiza ação alguma.

A orquestração pode ser realizada pelas linguagens:

WS-BPEL

BPEL4WS

2.4 Enterprise Service bus - ESB

O papel do ESB (Enterprise Service Bus) dentro de uma arquitetura SOA é

fornecer uma infra-estrutura para dar suporte aos princípios de projetos SOA,
virtualizando os serviços providos e tornando toda tecnologia da informação
transparente para o negócio (Junior, 2007).
Em uma arquitetura SOA, o ESB atua no papel de prover independência de
linguagem, transparência de protocolo e localização, independência de formato de
dados, independência de plataforma e um modelo de comunicação transparente para que
seja possível atingir um baixo acoplamento entre os serviços componentes da
arquitetura(Junior, 2007).
 A Figura 8 mostra a mudança entre a interação das aplicações sem atuação, e
com a atuação do ESB.

Figura 8 - Integração de Aplicação web (Junior ,2007) com adaptações

Segundo Junior (2007), o ESB pode simplificar a integração entre aplicações,

que antes precisavam conhecer a interface (tecnologias, padrões, formatos, localização)
de cada diferente serviço. Assim, a mudança em um serviço impactava fortemente
vários componentes e as aplicações precisavam conhecer várias interfaces. Com o ESB,
as aplicações conhecem uma interface (a do ESB) e a tarefa de conversão dos diversos
padrões e tecnologias passa a ser feito por ele, o que simplifica a aplicação e a isola de
possíveis mudanças.

2.5 WS-I Profiles and Web Services Architecture

Esse padões foram desenvolvido para promover a evolução do padrão de indústria de serviços,
interoperabilidade de plataformas de serviços da Web, padrões de arquitetura e de
especificações do perfil de tecnologia, foram desenvolvidos pelo WS-I e W3C, respectivamente
os padrões:

WS-I Basic Profile 1.0a

WS-I Basic Profile 1.1
WS-I Basic Profile 1.2
WS-I Basic Security Profile 1.0
WS-I Basic Security Profile 1.1
WS-I Simple SOAP Binding Profile 1.0
WS-I Attachments Profile 1.0
Web Services Architecture
 2.6 Context and Transaction Management

O conjunto inicial de tecnologias de serviços da Web não tinha a capacidade para dar suporte ao
contexto dos serviços ao longo de uma atividade de serviço. Sem a atividade de contexto em
estado ativo, o serviços Web pode agir de forma independente e não podendo suportar
transações distribuídas.

A especificação WS-Coordination fornece um sistema de gerenciamento de contexto, que é

aplicado para suportar transações atômicas e longa duração, utilizando protocolos descritos na
especificação WS-Transaction.

A transação atômica parte da especificação WS-Transaction é substituída por uma especificação

em separado intitulado WS-AtomicTransaction. Da mesma forma, a especificação WS-
BusinessActivity substitui o tipo correspondente de coordenação por definição sendo o WS-
Transaction.

Tipos de especificações de transações:

WS-Coordination
WS-Transaction (and the WS-TX TC)
WS-AtomicTransaction
WS-BusinessActivity

2.7 Padrões de seguraça

Provavelmente a maior diferença na plataforma de serviços de primeira geração da Web era

uma ausência de normas de segurança real. Conseqüentemente, as organizações estavam
relutantes em expor os processos de negócio através da Internet.

O framework WS-Security institui-se sendo um modelo de segurança completa que consiste de

uma pilha de especificações complementares. Estabelecendo medidas de segurança para
proteger mensagens SOAP ao longo do caminho da mensagem, e apoia a criação de políticas ea
unificação dos limites de confiança. A essencia das especificações WS-Security são ainda
complementadas por uma série de especificações de segurança estabelecidas por XML.

Padrões de segurança:

WS-Security (and the WS-SX TC)

WS-Federation
WS-SecureConversation
WS-Trust
XML Encryption
XML Signature
XKMS
XACML
SAML
WS-I Basic Security Profile
 2.8 Confiabilidade, roteamento, e Anexos

Para que a automação seja uma solução em nível empresarial, o framework de comunicação
deve ser à prova de falhas, flexível e eficiente. As seguintes especificações WS-* propõem
funcionalidades críticas de recursos que lidam com a entrega confiavel de mensagens, auto-
governo de mensagens, e anexos de mensagens.

Os padrões são:

WS-ReliableMessaging (and the WS-RX TC)

WS-Attachments
SwA
DIME

2.9 Politicas de Metadados

Dentro de uma empresa orientada a serviços, seria útil para ser capaz de abstrair regras de alto
nível empresarial, normas de segurança, e as propriedades descritivas para que possam ser
aplicados a grupos de serviços, como políticas.

O framework WS-Policy consiste de um conjunto de especificações que permitem a descrição

de tais políticas, bem como uma forma padrão de anexá-los aos serviços da Web. WS-
MetadataExchange complementa WS-Policy (e WSDL), proporcionando um meio padronizado
de serviços da Web para consulta de metadados.

Os padrões são:

WS-Policy
WS-PolicyAssertions
WS-PolicyAttachments
WS-MetadataExchange

2.10 Outros padrões

WS-CDL (Choreography Description Language)

WS-Eventing
WS-Notification
WS-RF (Resource Framework)

Referências

ERL, Thomas . SOA specifications, Specifications that relate to SOA and service-
orientation. Disponivel em: < http://www.whatissoa.com/soaspecs/default.php>,
acessado em 29 de Março de 2011.

TAMASAUKAS FILHO, Antonio; RIBEIRO NETO, Benedito de Souza &

SOUSA, Danilo de. UMA EXTENSÃO DO OPEN UP/BASIC PARA
MODELAGEM DE SERVIÇOS SOA. Centro universitário do Pará – CESUPA,
Trabalho de conclusão de Curso, Belém-Pa, 2009.