Computação Orientada aos Serviços
Introdução – Semestre de Inverno 14/15
Arquiteturas de Sistemas: Centralizadas
Terminal
Terminal
Terminal
Terminal
Terminal
Terminal
Terminal
Terminal
Mainframe
Terminal
Terminal
Terminal
Terminal
Terminal
Cátia Vaz 2014/2015
Arquiteturas de Sistemas: Cliente-Servidor
PC
Client
E-Mail
Server
Workstation
Client
PC
Client
Web
Server
PC
Client
Database
Server
Cátia Vaz 2014/2015
Arquitetura de Sistemas: Computação entre
pares (peer-to-peer)
Application
Application
Application
Application
E-Mail
System
Web
System
Database
Server
Cátia Vaz 2014/2015
Como tem sido a Web
} 
Desenhada para as pessoas obterem informação
}  Focada no aspecto visual
}  Com falta de suporte para o significado
}  Suporta interações baixo nível
}  Usualmente cria dependências entre o que
deveriam ser componentes indepententes.
Cátia Vaz 2014/2015
Como se está a tornar a web
} 
Permite interações entre partes autónomas,
heterogéneas (utilizadores e fornecedores de
informação)
}  Suporta interfaces standartizadas à Web services
}  Suporta atividades complexasà processos
}  Suporta interações mais ricas entre as partes
autónomas à agentes
}  Vai mais além do aspecto visual para capturar o
significado à Web Semântica
Cátia Vaz 2014/2015
Arquitetura de Sistemas: Cooperativos
} 
A próxima geração emergente é constituída por sistemas
de informação cooperativos
} 
Nestes sistemas, as componentes heterogéneas, autonómas e
ativas fornecem uma solução colectiva, interagindo umas com
as outras.
Cátia Vaz 2014/2015
Evolução das redes
} 
Redes locais proprietárias
} 
Redes virtuais privadas (VPN)
} 
} 
Redes privadas restritas a uma determinada instituição
(intranet)
Redes privadas restritas a um conjunto de empresas
selecionadas (extranet)
Internet
}  A evolução das redes implicou que os sistemas passassem
a ser abertos.
} 
Cátia Vaz 2014/2015
Características dos sistemas abertos
-  Autonomia;
-  Heterogeneidade;
-  Dinamismo;
Cátia Vaz 2014/2015
Como suportar as características anteriores
}  Reduzir a partilha de dados e metadados de modo a
eliminar inconsistências e anomalias
} 
Reduzir o hard-coding
} 
} 
} 
} 
} 
Ligação dinâmica às componentes
Usar formatos standartizados para expressar dados
Expressar conhecimento através de metadados
Usar linguagens standard.
Relaxar as restrições de consistência
} 
} 
Obter conhecimento remoto apenas quando necessário
Corrigir em vez de prevenir violações de restrições.
Cátia Vaz 2014/2015
Computação Orientada aos Serviços
} 
A computação orientada aos serviços é um
paradigma emergente para desenvolver aplicações
distribuídas, adaptáveis e interoperáveis.
} 
Um serviço é uma componente autónoma e
independente da plataforma que pode ser descoberto e
utilizado por outros serviços.
} 
} 
São utilizadas linguagens standards para descrever o protocolo
dos contratos, as interfaces e os formatos dos dados
São expostos através de um determinado medium de
comunicação (ex: Internet)
Cátia Vaz 2014/2015
Computação Orientada aos Serviços
} 
A computação orientada aos serviços tem como
vantagens:
} 
Reutilização
} 
Eficiência
} 
Perda de acoplamento tecnológico (loose technology coupling)
} 
Divisão de responsabilidade
Cátia Vaz 2014/2015
Composição de Serviços
} 
Visão
} 
} 
} 
Especificar e fornecer serviços de forma independente,
escondendo as implementações.
Combinar serviços existentes para criar novos serviços
Ir além da ideia de “componente passiva”
}  Obviamente
} 
desejável e desafiante
Mas será que é o pretendido?
} 
} 
} 
As implementações podem estar escondidas?
E a visibilidade organizacional?
Como manipular excepções?
Cátia Vaz 2014/2015
Aplicação de Serviços Compostos
} 
} 
} 
} 
} 
} 
Portais
Interoperabilidade entre sistemas legacy
E-commerce
Empresas Virtuais
Grid computing
…
Cátia Vaz 2014/2015
Web services
} 
Um Web service é a tecnologia mais utilizada no
contexto da computação orientada aos serviços
} 
Um Web service é um serviço em que o medium de
comunicação é a Internet
} 
A de facto linguagem standard que define os serviços é o WSDL
(Web Service Description Language)
} 
http://www.xmethods.com/ve2/index.po
Cátia Vaz 2014/2015
Web Services Stack
Security
OWL-S, WSMO, ...
Semantic
WS-BPEL, WS-CDL...
Integration
Correctness
Coordination
Quality of Service
Reliability
Policy
Transaction
UDDI
Publication/Discovery
WSDL, WADL, ...
Description
SOAP, REST,...
Messaging
XML...
Encoding
HTTP, SMTP, SIP, ...
Transport
Adaptado de http://www.w3c.org
Cátia Vaz 2014/2015
Computação Orientada aos Serviços
Standards para Serviços Web – Semestre de Inverno 14/15
O modelo geral de Arquitectura para Web
Services (SOA)
} 
A arquitectura para os serviços Web é estabelecida em
princípios e standards para:
} 
Conexão
} 
Comunicação
} 
Descrição
} 
Descoberta
Service
Broker
Publish or
announce
(WSDL)
Service
Provider
Registry
Find or
discover
(UDDI)
Bind or
invoke
(SOAP)
Cátia Vaz 2014/2015
Service
Requestor
} 
} 
} 
} 
} 
} 
} 
} 
Contrato dos serviços standartizado
Serviços loosely coupled
Abstracção do serviços
Reutilização do serviços
Autonomia do serviços
Serviços stateless
Composicionalidade de serviços
Descoberta de serviços
Cátia Vaz 2014/2015
Interoperabilidade de serviços
Princípios
WSDL: Web Services Description Language
} 
Descreve uma interface programática para um Web
service, incluindo:
} 
Definições dos tipos de dados
} 
Formatos de mensagens de input e output
} 
As operações dadas pelo serviço
} 
Endereço da rede
} 
Protocol bindings
Cátia Vaz 2014/2015
Exemplo WSDL
<?xml version ="1.0"?>
<!−− the root element , wsdl : definitions, defines a set of related services −−>
<wsdl : definitions name="Temperature"
targetNamespace="http://www.socweather.com/schema"
xmlns : ts="http://www.socweather.com/TempSvc.wsdl"
xmlns : tsxsd="http://schemas.socweather.com/TempSvc.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Cátia Vaz 2014/2015
Exemplo WSDL (continuação 1)
<!−− wsdl : types encapsulates schema definitions of communication types ; here using xsd −−>
<wsdl: types>
<!−− all type declarations are expressed in xsd −−>
<xsd:schema
targetNamespace="http://namespaces.socweather.com"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<!−− xsd def : GetTemp [ City string , When string ] −−>
<xsd : element name="GetTemp">
<xsd:complexType>
<xsd:sequence>
<xsd: element name="City" type="string"/>
<xsd: element name="When" type="string"/>
</ xsd:sequence>
</xsd:complexType>
</xsd:element>
Cátia Vaz 2014/2015
Exemplo WSDL (continuação 2)
<!−− xsd def: GetTempResponse [ DegreesCelsius integer ] −−>
<xsd : element name="GetTempResponse">
<!−− XML Schema entry as above −−>
</ xsd:element>
<!−− xsd def : GetTempFault [ errorMessage string ] −−>
<xsd : element name="GetTempFault">
<!−− XML Schema entry as above −−>
</ xsd:element>
</xsd:schema>
</ wsdl:types>
<!−− wsdl :message elements describe potential transactions. Most messages , as here ,-- >
<!−− have only one part . Multiple parts provide a way to aggregate complex messages −−>
<!−− request GetTempRequest is of type GetTemp −−>
<wsdl:message name="GetTempRequest">
<wsdl: part name="body" element="tsxsd:GetTemp"/>
</ wsdl:message>
Cátia Vaz 2014/2015
Exemplo WSDL (continuação 3)
<!−− response GetTempResponse is of type GetTempResponse −−>
<wsdl:message name="GetTempResponse">
<wsdl : part name="body" element="tsxsd:GetTempResponse"/>
</ wsdl:message>
<!−− wsdl :portType describes messages in an operation−−>
<wsdl:portType name="GetTempPortType">
<wsdl : operation name="GetTemp">
<!−− The order input preceding output indicates the −−>
<!−− request−response operationtype−−>
<wsdl : input message="ts:GetTempRequest"/>
<wsdl : output message="ts:GetTempResponse"/>
<wsdl : fault message="ts:GetTempFault"/>
</ wsdl : operation >
</ wsdl:portType>
( ...)
Cátia Vaz 2014/2015
WSDL
Data
Model
definitions
targetNamespace=thisNamespace
xmins:tns=thisNamespace
types
message name=in
message name=out
portType name=foo
operation
input message=tns:in
output message=tns:out
binding name=foobar
type=tns:foo
[binding information]
Tipos contêm definições de
tipos de dados
Ex: GetTemp
Types contains data type definitions
Messages consist of one or more parts
Mensagens consistem em uma
ou mais partes
AEx:GetTempRequest
portType describes an abstract set
of operations
Um binding descreve um
conjunto concreto de formatos
A binding describes a concrete set of
formats
and protocols forpara
the foo os port types
e protocolos
portTypes
service name=foobar Service
Port name=foobarPort
binding=tns:foobar
[endpoint information]
Um port descreve uma
Aimplementação
port describes an implementation
de um
of the foobar binding
determinado binding
Cátia Vaz 2014/2015
Diretório de Serviços
} 
Suporta descoberta
} 
} 
Permite às aplicações, agentes, Web service providers, Web
service requestors, pessoas, objectos, procedimentos,
localizarem-se entre si.
Tipos de Diretórios:
} 
} 
} 
White pages: entradas procuradas por nome
Yellow pages: entradas procuradas pelas suas características
Um directório pode ser uma simples base de
dados (passiva) ou um broker (activo, dando
alertas e recrutando participantes)
}  Standards
} 
} 
UDDI
ebXML
de Diretórios
Cátia Vaz 2014/2015
UDDI: Universal Description, Discovery, and
Integration
} 
UDDI suporta as white e yellow pages.
UDDI é um Web service baseado em SOAP e XML.
} 
UDDI regista
} 
} 
} 
tModels: descrições técnicas do comportamento de um
serviço
businessEntities: descrevem a especificação dos múltiplos
tModels
Cátia Vaz 2014/2015
WSDL ßà UDDI
WSDL
UDDI
Service Implementation
<import>
<service>
<port>
BusinessEntity
BusinessService
<port>
BindingTemplate
BindingTemplate
Service Interface
<types>
<message>
tModel
<portType>
<binding>
Cátia Vaz 2014/2015
Computação Orientada aos Serviços
Programar Web services – Semestre de Inverno 13/15
REST (Representational State Transfer)
REST é um estilo de arquitectura para sistemas
em rede que restringe a semântica de conexão (não
a semântica de componentes)
}  A Web é uma rede de recursos hyperlinked
} 
} 
} 
Um recurso é algo identificado por um URI.
Uma aplicação na web funciona como uma máquina
de estados:
} 
Quando uma aplicação cliente selecciona um link gera
uma transição de estado, resultando na recepção da
próxima página (próximo estado) da aplicação
Cátia Vaz 2014/2015
Exemplo REST: Bibsonomy API REST (1)
} 
Para listar todos os utilizadores do Bibsonomy (por omissão
só lista 20)
} 
} 
http://www.bibsonomy.org/api/users
Resposta:
<bibsonomy stat="ok">
<users next="http://www.bibsonomy.org/api/users?start=20&end=40" end="20" start="0">
<user href="http://www.bibsonomy.org/api/users/#8raijin" name="#8raijin">
<groups end="0" start="0"/></user>
<user href="http://www.bibsonomy.org/api/users/#beet" name="#beet">
<groups end="0" start="0"/></user>
<user href="http://www.bibsonomy.org/api/users/(health_n_fitnes"
name="(health_n_fitnes"><groups end="0" start="0"/></user>
<user href="http://www.bibsonomy.org/api/users/*alex*" name="*alex*"><groups end="0"
start="0"/></user>
...
</users>
</bibsonomy>
Cátia Vaz 2014/2015
Exemplo: Bibsonomy API REST (2)
} 
} 
Bibsonomy é um registo social de publicações científicas e um
sistema de partilha
BibSonomy fornece um web service usando REST
} 
} 
http://www.bibsonomy.org/
A BibSonomy permite:
} 
} 
} 
} 
} 
} 
} 
} 
Obter a lista de todos os utilizadores;
Obter detalhes de um determinado utilizador;
Criar um utilizador;
Eliminar um utilizador;
Criar um post;
Mudar um post;
Eliminar um post;
...
Cátia Vaz 2014/2015
Exemplo: Bibsonomy API REST (3)
} 
Permite a mudança de estado:
} 
http://www.bibsonomy.org/api/users/cvaz
<bibsonomy stat="ok">
<user href="http://www.bibsonomy.org/api/users/cvaz" toClassify="1" spammer="false"
email="[email protected]" realname="" name="cvaz"><groups end="0“ start="0"/>
</user>
</bibsonomy>
Cátia Vaz 2014/2015
Características do REST
} 
Interações cliente-servidor
}  Statelessness:
pedidos não podem tirar proveito
de contextos armazenados num servidor
}  Cache: respostas podem ser identificadas como
cacheable
}  Interface uniforme: URIs, URLs
}  Componentes em camadas
} 
Foca-se nos recursos em vez dos métodos
} 
Lê, constroi, altera e remove um recurso
Cátia Vaz 2014/2015
Para desenhar um REST Web service
(1) Identificar todas as entidades conceptuais que se
pretende expor;
}  (2) Criar um URL para cada recurso
} 
} 
} 
Ex: http://www.bibsonomy.org/api/users/catia.vaz
(3) Categorizar os recursos consoante os clientes apenas
recebam uma representação do recurso, possam
adicionar, modificar, ou eliminar o recurso
} 
} 
} 
} 
GET (sem efeitos colaterais)
PUT
POST
DELETE
Cátia Vaz 2014/2015
Para desenhar um REST Web service
(4) Especificar o formato da resposta usando um esquema
}  (5) Descrever como os serviços serão invocados, usando
um documento WSDL ( ou um HTML )
} 
Cátia Vaz 2014/2015
Exemplo: Bibsonomy API REST (2)
Description
HTTP
Path
List of all users
GET
/users
Create a user
POST
/users
Details for a user
GET
/users/[username]
Change user details
PUT
/users/[username]
Delete user
DELETE
/users/[username]
List of posts for a users
GET
/users/[username]/posts ?tags=[t1+t2+...+tn] ?
resourcetype=(bibtex|bookmark)
Create post
POST
/users/[username]/posts
Details for a post
GET
/users/[username]/posts/[resourceHash]
Change post
PUT
/users/[username]/posts/[resourceHash]
Delete post
DELETE
/users/[username]/posts/[resourceHash]
...
...
...
Cátia Vaz 2014/2015
Exemplo: Twitter API Rest
}  https://dev.twitter.com/docs/api
}  http://twitter.com/statuses/
user_timeline.xml?id=joelcomm
}  Diferenças da Bibsonomy API Rest?
Cátia Vaz 2014/2015
Verbos HTTP
} 
Verbos
} 
} 
} 
} 
} 
} 
GET (sem efeitos colaterais)
PUT
POST
DELETE
Em particular, pode-se utilizar os métodos GET e POST para
substituir a maior parte das operações/métodos definidos em
esquemas SOAP
Operações idempotentes
Cátia Vaz 2014/2015