IFPA

Tecnologia em Análise e Desenvolvimento de Sistemas (TADS)

Práticas de Engenharia de
Software
Arquitetura Orientada a Serviços

PROFESSOR: Claudio Roberto de Lima Martins

claudiomartins2000@gmail.com
1
 2
Tópicos abordados na aula

 Arquitetura de Software (Revisão)

 Serviços como componentes reutilizáveis
 Serviços de engenharia
 Desenvolvimento de software com serviços
 3

Arquitetura de Software
 4
Arquitetura de Software
▶ “A arquitetura de software é a organização fundamental de um
sistema, incorporada em seus componentes, suas relações entre si e
o ambiente, e os princípios que governam seu design e evolução”
 (IEEE 1471-2000)

▶ “A arquitetura estabelece o contexto para projeto e implementação”

“As decisões de arquitetura são as decisões mais fundamentais;

mudá-los terá efeitos em cascata significativos ”.
 5
Preocupações com a arquitetura de software
 6
Estilos arquiteturais
▶ Estilos arquiteturais definem meios de selecionar e apresentar
blocos de construção de arquitetura.
▶ Há algumas formas de classificar e organizar os estilos
arquiteturais, observando alguns critérios. Por exemplo, o modelo
ou a categoria.
 7
Categorias de estilos

Categoria Estilo
Comunicação Orientada a Serviços (SOA) e Enterprise Service
Bus (ESB)
Operação Client/Server, N-Camadas e 3 Camadas
(Deployment)
Domínio Domain-Driven Design (DDD)
Estrutura Baseda em Componentes, Orientada a Objetos e em
Layers
 8
Relação dos modelos de arquitetura mais comuns
Estilo Resumo
Client/Server Separar o sistema em duas aplicações, onde o cliente faz requisições para o
servidor.
Componentes Decomposição da estrutura da aplicação em funções reutilizáveis ou
componentes expostos com interface de comunicação bem definida.
Domain-Driven Modelo de arquitetura orientada a objetos com a modelagem focada no
Design domínio de negócio e definição de objetos de negócio baseado em
entidades dentro do domínio de negócio.
Layers Conceito de organização da aplicação em uma pilha de camadas.
Message Bus Modelo de arquitetura no qual o software pode receber e enviar
mensagens utilizando um ou mais canais de comunicação, para que as
aplicações possam interagir sem precisar conhecer detalhes específicos
sobre cada outra.
N-Camadas (tiers) Desmembra funcionalidades em segmentos separados na mesma camadas
lógica (layer), mas com cada segmento alocado em um camada física
diferente, ou seja, separado fisicamente em outro computador.
Orientada a Objetos Paradigma de estrutura baseado na divisão de responsabilidades para um
aplicação ou sistema com reutilização individual e objetos auto suficientes,
cada um contendo dados em comportamento relevantes a seu objeto.
Orientada a Aplicações que expõe e consome funcionalidades como um serviço
Serviços utilizando contratos e mensagens.
 9

Arquitetura Orientada a Serviços

Sommerville – Chapter 18 Service-oriented software engineering

 10
Serviços Web
▶ Um Web Service é uma instância de uma noção mais geral de um
serviço:
 "Um ato ou desempenho oferecido por uma parte à outra. Embora o processo
possa estar vinculado a um produto físico, o desempenho é essencialmente
intangível e normalmente não resulta em posse de qualquer dos fatores de
produção ".
▶ Portanto, a essência de um serviço, é que a prestação do serviço é
independente da aplicação que usa o serviço.
▶ Prestadores de serviços podem desenvolver serviços especializados
e oferecem estes a uma variedade de usuários de serviços de
diferentes organizações.
 11
Arquitetura Orientada a Serviços
▶ Arquitetura Orientada a Serviços (SOA, em inglês) é uma
abordagem para desenvolver sistemas distribuídos em que os
componentes são serviços autônomos.
▶ Serviços podem executar em diferentes computadores a partir de
diferentes fornecedores de serviços.
▶ Foram desenvolvidos protocolos-padrão para dar suporte à
comunicação de serviços e troca de informações.
 SOAP
 REST
 12
Arquitetura Orientada a Serviços
▶ Modelo da arquitetura baseada em SOAP/WSDL
 SOAP (Simple Object Access Protocol) é um protocolo de comunicação que
formata as mensagens (enviadas e recebidas) em XML.
 WSDL (Web Services Description Language - Linguagem de Descrição de Serviços
Web)

WSDL é uma interface de acesso a um webservice e o SOAP é o protocolo utilizado para

trocar mensagens entre o webservice e aplicação.
Por meio de um WSDL você informa ao cliente como cada serviço em um end-point deve ser
invocado: quais os parâmetros e tipo de dados de cada parâmetro é esperado, e qual o tipo
de dado do retorno será enviado como resposta.
 13
Benefícios de SOA
▶ Serviços podem ser prestados internamente (dentro da
organização) ou terceirizados por provedores externos.
▶ Os serviços são independentes da linguagem e das tecnologias de
implementação dos sistemas.
▶ Investimentos em sistemas legados podem ser preservados.
▶ A computação entre as organizações é facilitada por meio da troca
simplificada de informações.
 14
Padrões relacionadas à SOA
▶ SOAP
 Um padrão de troca de mensagens que suporta a comunicação de serviço.

▶ WSDL (Web Service Definition Language)

 Esse padrão permite que sejam definidas uma interface de serviços e suas
vinculações.
▶ REST
 Trabalha sobre o protocolo HTTP puro, portanto não depende do protocolo
SOAP para realizar a comunicação e não usa a interface WSDL.
▶ WS-BPEL
 Um padrão para linguagens de workflow usado para definir a composição de
serviços.
 15
Padrões relacionadas à SOA
▶ Padrões envolvidos com Serviços Web usando SOAP

Transporte (HTTP, HTTPS, SMTP, etc)

 16
Exemplo de um Cenário de Serviços
▶ Um sistema de informação no interior de um veículo oferece aos
motoristas informações sobre o clima, condições do tráfego
rodoviário, etc.
▶ Tal sistema está ligado ao rádio do carro para que a informação
seja entregue como um sinal em um canal de rádio específico.
▶ O carro é equipado com receptores GPS para descobrir a sua
posição e, com base nessa posição, o sistema acessa uma gama de
serviços de informação.
▶ As informações podem ser entregues na linguagem especificada
pelo motorista.
 17
Exemplo de um Cenário de Serviços
▶ Um sistema de informações de bordo baseado em serviços
 18
Vantagens da SOA para a aplicação exemplo (Veículo)
▶ Não é necessário decidir quando o sistema é programado
ou implantado, qual prestador do serviço deve ser usado
ou quais serviços específicos devem ser acessados.
 Como o carro se move, o software usa o serviço de descoberta
de serviços para encontrar o serviço de informação mais
adequado e se conecta a esse.
 Por causa do uso de um serviço de tradução, ele pode mover-se
através das fronteiras e, portanto, tornar as informações locais
disponíveis para as pessoas que não falam o idioma local.
 19
Engenharia de software orientada a serviços
▶ Abordagens existentes para a engenharia de software precisam
evoluir para refletir a abordagem orientada a serviços para o
desenvolvimento de software.
 Engenharia de serviços. O desenvolvimento de serviços traz confiança a
componentes reutilizáveis.
 Segue a abordagem de desenvolvimento de software para reuso.
 Desenvolvimento de software com serviços. É o desenvolvimento de
software confiável, no qual os serviços são componentes fundamentais.
Neste caso, segue o modelo desenvolvimento de software com reuso.
▶ Construir aplicativos baseados em serviços permite que empresas e outras
organizações cooperem e façam uso das funções de negócios umas das outras.
▶ Aplicativos baseados em serviços podem ser construídos por meio da vinculação
de serviços de vários provedores usando uma linguagem de programação padrão
ou uma linguagem de workflow (fluxo de trabalho) especializada.
 20
Serviços como componentes reusáveis
▶ Um serviço pode ser definido como:
 Um componente de software reutilisável de baixo acoplamento, que
encapsula funcionalidade discreta a qual pode ser distribuída e acessada por
meio de programas.
▶ Um web service é um serviço que é acessado usando protocolos-
padrão de Internet e é baseado em XML (ou outro formato
padrão).
 21
Linguagem de descrição de web services (SOAP)
▶ A interface de serviço é definida em uma descrição de serviço
expressa em WSDL (Web Service Description Language).
▶ A especificação WSDL define:
 As operações as quais o serviço oferece suporte e o formato das mensagens
que são enviadas e recebidas pelo serviço.
 Como o serviço é acessado - isto é, os mapas de ligação da interface abstrata
em um conjunto concreto de protocolos.
 Onde o serviço está localizado. Geralmente esse é expresso como uma URI
(Universal Resource Identifier).
 22
Organização de uma especificação WSDL
 23
Componentes da especificação WSDL
▶ A parte 'o que' de um documento WSDL, chamada de interface,
especifica as operações que o serviço suporta, e define o formato
das mensagens que são enviadas e recebidas pelo serviço.
▶ A parte ‘como’ de um documento WSDL, chamada de ligação,
mapeia a interface abstrata para um conjunto concreto de
protocolos.
▶ A ligação especifica os detalhes técnicos de como se comunicar
com um web service.
▶ A parte ‘onde’ de um documento WSDL descreve a localização de
uma implementação específica de web service (o seu “end-point” -
ponto final).
 24
Parte de uma descrição WSDL para um web service
▶ Define alguns dos tipos usados.
▶ Suponha que o prefixo do namespace ‘ws’ se refira ao namespace
URI para o esquema XML e o prefixo namespace associatado com
essa definição seja “weathns”.
<types>
<xs: schema targetNameSpace = “http://.../weathns” xmlns: weathns = “http://…/weathns” >
<xs:element name = “PlaceAndDate” type = “pdrec” />
<xs:element name = “MaxMinTemp” type = “mmtrec” />
<xs: element name = “InDataFault” type = “errmess” />

<xs: complexType name = “pdrec”

<xs: sequence>
<xs:element name = “town” type = “xs:string”/>
<xs:element name = “country” type = “xs:string”/>
<xs:element name = “day” type = “xs:date” />
</xs:complexType>
-- Definitions of MaxMinType and InDataFault here
</schema>
</types>
 25
Parte de uma descrição WSDL para um web service
▶ Agora, defina a interface e suas operações.
▶ Neste caso, existe apenas uma operação para retornar as
temperaturas máximas e mínimas.

<interface name = “weatherInfo” >

<operation name = “getMaxMinTemps” pattern = “wsdlns: in-out”>
<input messageLabel = “In” element = “weathns: PlaceAndDate” />
<output messageLabel = “Out” element = “weathns:MaxMinTemp” />
<outfault messageLabel = “Out” element = “weathns:InDataFault” />
</operation>
</interface>
 26

RESTful services
 27
Web Services Restful
▶ Web services padrões (como SOAP) têm sido criticados como
padrões “pesados”, superficiais e ineficientes.
▶ REST (Representational State Transfer) é um estilo de arquitetura
baseado na transferência de representações de recursos de um
servidor para um cliente.
▶ Esse estilo reforça a web como um todo e é mais simples que o
SOAP/WSDL para implementação de web services.
▶ Serviços RESTFul envolvem uma menor sobrecarga do que os
chamados “web services grandes" e são usados por muitas
organizações que executam serviços baseados em sistemas que
não dependem de serviços fornecidos externamente.
 É a tecnologia mais indicada para implementar a arquitetura de
“microserviços” (a ver em breve)
 28

Resources
▶ O element fundamental na arquitetura RESTful é um
recurso (resource).
▶ Essencialmente, um recurso é um simples elemento de
dados tal como um catalogo, um registro médico, ou um
documento, tal como um capítulo de livro.
▶ Em geral, recursos podem ter multiplas representações,
i.e. eles podem existir em diferentes formatos.
 MS WORD
 PDF
 Planilha (XLS, Excel)
 Arquivos texto (Texto puro, CSV, XML, etc)

26/11/2014 Chapter 18 Service-oriented software engineering

 29

Operações com o Recurso

▶ Create – cria o recurso (persiste/salva o valor/estado).
▶ Read – retorna uma representação do recurso.
▶ Update – muda o valor do recurso.
▶ Delete – faz o recurso inacessível (na prática, apaga-se o
recurso).
 30

Recursos e ações
 31

Functionalidades das Operações

▶ POST
 POST é usado para criar um recurso. Possui dados associados
definidos ao recurso.
▶ GET
 GET é usado para ler o valor de um recurso e retorná-lo ao
solicitante na representação especificada, como XHTML, que
pode ser renderizado em um navegador da web.
▶ PUT
 é usado para atualizar o valor de um recurso.
▶ DELETE
 é usado para excluir o recurso.
 32

Resource access
▶ When a RESTful approach is used, the data is exposed and
is accessed using its URL.
▶ Therefore, the weather data for each place in the
database, might be accessed using URLs such as:
 http://weather-info-example.net/temperatures/boston
http://weather-info-example.net/temperatures/edinburgh
▶ Invokes the GET operation and returns a list of maximum
and minimum temperatures.
▶ To request the temperatures for a specific date, a URL
query is used:

 http://weather-info-example.net/temperatures/edinburgh?date=20140226
 33

Query results
▶ The response to a GET request in a RESTful service may
include URLs.
▶ If the response to a request is a set of resources, then the
URL of each of these may be included.
 http://weather-info-example.net/temperatures/edinburgh-scotland
http://weather-info-example.net/temperatures/edinburgh-australia
http://weather-info-example.net/temperatures/edinburgh-maryland
 34

Disadvantages of RESTful approach

▶ When a service has a complex interface and is not a
simple resource, it can be difficult to design a set of
RESTful services to represent this.
▶ There are no standards for RESTful interface description
so service users must rely on informal documentation to
understand the interface.
▶ When you use RESTful services, you have to implement
your own infrastructure for monitoring and managing the
quality of service and the service reliability.
 35

Combinando APIs RESTful e SOAP

 36

Exemplo de Serviço REST:

https://hgbrasil.com/status/weather/
 37

Documentação do serviço de clima

 38

Exemplo: pesquisando o clima de Belém (BRXX0032)

https://api.hgbrasil.com/weather/?format=json&cid=BRXX0032
 39

Engenharia de Serviço
 40
Exemplo de WebService usando Restful
▶ O processo de desenvolvimento de serviços para reuso em
aplicações orientados a serviços.
▶ O serviço precisa ser concebido como uma abstração reusavel que
possa ser usada em diferentes sistemas.
▶ Geralmente, deve ser projetada uma funcionalidade útil associada
à abstração e o serviço deve ser robusto e confiável.
▶ O serviço deve ser documentado de modo que possa ser
descoberto e compreendido pelos potenciais usuários.
 41
O processo de Engenharia de Serviços
 42
Estágios da Engenharia de Serviços
▶ Identificação do serviço.
 É a identificação de um serviço candidato, em que você
identifica possíveis serviços que possam ser implementados e
define os requisitos de serviço.
▶ Projeto de serviço
 Em que você projeta a lógica e as interfaces de serviços, além
da implementação dessas interfaces (SOAP e/ou RESTful)
▶ Implementação e implantação de serviço
 Aqui você implementa e testa o serviço e disponibiliza para uso.
 43
Identificação dos serviços candidatos
▶ Serviços devem apoiar processos de negócio.
▶ Identificação de serviço candidato envolve a compreensão e análise
dos processos de negócios de uma organização para decidir quais
serviços reusáveis poderiam ser implementados para apoiar esses
processos.
▶ Três tipos fundamentais de serviços:
 Serviços utilitários públicos que implementam alguma
funcionalidade geral usada por diferentes processos de negócio.
 Serviços de negócios que estão associados com uma função
específica de negócios, por exemplo um registro de estudante
universitário.
 Serviços de coordenação ou de processo que suportam os
processos de coordenação, como um serviço de pedidos.
 44
Serviços orientados a tarefas e entidades
▶ Serviços orientados a tarefas são aqueles associados com alguma
atividade.
▶ Os serviços orientados a entidades são como objetos. Eles estão
associados a uma entidade empresarial, tal qual um formulário de
pedido de emprego.
▶ Serviços de negócios ou de utilidade pública podem ser orientados
a entidades – ou tarefas.
▶ Serviços de coordenação sempre são orientados a tarefas.
 45
Classificação do serviço
 46
Pontos importantes sobre Engenharia de Serviços
▶ O serviço está associado a uma única entidade lógica usada em
diferentes processos de negócios?
▶ A tarefa é executada por pessoas diferentes na organização? A
tarefa pode adotar um modelo RESTful?
▶ O serviço é independente?
▶ O serviço tem que manter o estado? É necessário um banco de
dados?
▶ O serviço poderia ser usado por clientes fora da organização?
▶ Os diferentes usuários do serviço têm diferentes requisitos não
funcionais?
 47
Exemplos de identificação de serviço
▶ Uma grande empresa, que vende equipamentos de informática,
conseguiu preços especiais para configurações aprovadas para
alguns clientes.
▶ Para facilitar a encomenda automatizada, a empresa pretende
produzir um serviço de catálogo que permitirá aos clientes
escolher o equipamento que eles precisam.
▶ Ao contrário de um catálogo de consumidor, os pedidos não são
colocados diretamente, por meio de uma interface de catálogo. Em
vez disso, os produtos são encomendados através do sistema de
compras baseado na web de cada empresa que acessa o catálogo
como um web service.
▶ A maioria das empresas têm seus próprios orçamentos e
procedimentos de aprovação de pedidos e encomendas. E deve
seguir seus próprios processos quando um pedido é colocado.
 48
Serviço de Catálogo
▶ Criado por um fornecedor para mostrar quais itens poderiam ser
encomendados por outras empresas.
▶ Requisitos de serviço:
 Deve ser criada para cada cliente uma versão específica do
catálogo.
 Os catálogo devem ser baixados pelos clientes.
 Podem ser comparadas as especificações e os preços de até 6
itens.
 Devem ser fornecidos recursos de navegação e pesquisa.
 Deve ser prevista uma função que permita que seja prevista a
data de entrega de itens encomendados.
 Devem ser colocadas ordens virtuais que reservam a
mercadoria por 48 horas para permitir a uma empresa que
coloque ordens.
 49
Requisitos não funcionais do Catálogo
▶ O acesso será restrito apenas a funcionários de
organizações credenciadas.
▶ Preços e configurações oferecidos para cada organização
serão confidenciais.
▶ O catálogo estará disponível a partir de 07h até 11h.
▶ O catálogo deve ser capaz de processar até 10
solicitações por segundo.
 50
Descrições funcionais de operações de serviços de catálogo
 51
Projeto de interface de serviço
▶ Envolve pensar sobre as operações associadas com o serviço e as
mensagens trocadas.
▶ Normalmente, o número de mensagens trocadas para completar
uma solicitação de serviço deve ser minimizado.
▶ O serviço de informações de estado podem precisar ser incluídos
nas mensagens.
 52
Estágios do Projeto de Interface
▶ Projeto lógico de interface
 Começa com os requisitos de serviço e define os nomes das operações e
parâmetros associados com o serviço. As exceções também devem ser
definidas.
▶ Projeto de Interface SOAP
 Projetar a estrutura e organização do input e output de mensagens.
Notações como a UML são uma representação mais abstrata do que as XML.
 Desenvolvimento WSDL
A especificação lógica é convertida em uma descrição WSDL.
▶ Projeto de Interface REST
 A definição das operações requeridas devem ser mapeadas em operações
REST e definer quais recursos são necessários.
 53
Exemplo de Projeto de Interface do Catálogo
 54

RESTful interface
▶ Deve haver um recurso representando um catálogo
específico da empresa. Isso deve deve ser feito na forma de
uma URL <catalogo-base>/<nome-companhia> e deve ser
criada usando uma operação POST.
▶ Cada item do catálogo deve ter sua própria URL na forma:
<catalogo-base>/<nome-companhia>/<identificados-item>.
▶ A operação GET é usada para recuperar itens.
 Lookup é implementado para usar a URL de um item em um
catálogo como um parâmetro de GET.
 Search é implementado para usar o GET de um catálogo da
compania como a URL e a busca é feita passando uma “string”
como parâmetro da consulta. Essa operação GET retorna uma lista
de URLs dos itens que combinam com a busca da pesquisa.
 55

RESTful interface
▶ A operação Compare pode ser implementada como um
sequência de operações GET, para recuperar itens
individualmente, seguido por uma operação POST para
criar uma tabela de comparação e no final a operação GET
retorna o resultado ao usuário.
▶ As operações CheckDelivery e MakeVirtualOrder
necessitam de um recurso adicional, representando um
pedido virtual.
 Uma operação POST é usada para criar este recurso com o
número de itens requeridos. A identificação (id) da empresa é
usada para automaticamente preencher o formulário de pedido
e entregar a data calculada da entrega. Essa informação é
recuperada usando uma operação GET.
 56
Implementação e implantação de serviço
▶ Implementação de serviço deve usar uma linguagem de
programação padrão ou uma linguagem de workflow.
▶ Assim, os serviços precisam ser testados por meio da
criação de mensagens de entrada e verificação da
possibilidade das mensagens de saída produzidas tal qual
esperadas como resposta.
▶ A implantação envolve a divulgação do serviço e
instalação desse em um servidor web.
 Os atuais servidores fornecem suporte para instalação de
serviço.
 57

Serviços de Sistemas Legados

▶ Uma importante aplicação de serviços é fornecer acesso à
funcionalidade embutida nos sistemas legados.
▶ Sistemas legados oferecem funcionalidade extensiva o
que pode reduzir o custo de implementação de serviço.
▶ Aplicações externas podem acessar essa funcionalidade
por meio de interfaces de serviços.
 58

Serviços fornecendo acesso a um sistema legado

 59
Descrição de Serviço
▶ Informações sobre o seu negócio, contatos, etc. são importantes
por razões de confiança.
▶ Os usuários de um serviço precisam confiar que o serviço não irá se
comportar maliciosamente.
▶ Uma descrição informal da funcionalidade fornecida pelo serviço
pode ajudar os usuários em potencial a decidirem se o serviço é
relevante para o trabalho deles.
▶ Uma descrição detalhada dos tipos de interface e da semântica das
operações deve ser gerada. Vale tanto para serviços SOAP quanto
os baseados em RESTful.
▶ Também é importante fornecer informações de assinatura que
permitem aos usuários se registrarem para obterem informações
sobre atualizações do serviço.
 60
Definição dos serviços (mensagens com entrada e saída)
 61

Composição de Serviços

Chapter 18 Service-oriented software engineering

 62

Desenvolvimento de Software com Serviços

▶ Os serviços existentes são compostos e configurados para
criarem novas composições de serviços e aplicações.
▶ Muitas vezes, a base para composição de serviços é um
workflow.
 Workflows são sequências lógicas de atividades que, juntos,
modelam um processo coerente de negócios.
 Por exemplo, prestam um serviço de reservas de viagens que
permite a coordenação das reservas de voos, hotéis e aluguel de
automóveis.

WORKFLOW DE RESERVA DE PACOTE DE FÉRIAS

 63

Construção de Serviço por Composição

 64

Construção de Serviço por Composição

▶ Formular workflow preliminar
 Nessa fase inicial de projeto de serviço, você usa os requisitos
para o serviço composto como base para a criação de um
projeto de serviço 'ideal'.
▶ Descobrir serviços
 Durante essa fase do processo, você busca os registros de
serviços ou catálogos para descobrir quais serviços existem,
quem fornece esses serviços e os detalhes da prestação do
serviço.
▶ Selecionar possíveis serviços
 Obviamente, a sua seleção de critérios incluirá a funcionalidade
dos serviços oferecidos. E também podem incluir o custo e a
qualidade dos serviços (capacidade de resposta, disponibilidade,
etc.) oferecidos.
 65

Construção de Serviço por Composição

▶ Refinar workflow
 Envolve a adição de detalhes para a descrição abstrata e, talvez,
adiciona ou remove as atividades do fluxo de trabalho.
▶ Criar programa de workflow
 Durante essa fase, o projeto abstrato de workflow é
transformado em um programa executável e a interface do
serviço é definida. É possível usar uma linguagem de
programação convencional, tal qual Java ou uma linguagem de
workflow, como WS-BPEL.
▶ Testar serviço ou aplicação completa
 O processo de testes do serviço composto completo, é mais
complexo do que os testes de componentes em situações em
que os serviços externos são usados.
 66

Projeto e implementação do Workflow

▶ WS-BPEL é uma padrão para especificação de workflow.
Contudo, as descrições em WS-BPEL são longas e difíceis
de ler.
▶ Notações gráficas de workflow, como BPMN, são mais
fáceis de ler e a WS-BPEL pode ser geradas a partir desses
diagramas.
▶ Em sistemas entre organizações, workflow separados são
criados para cada organização e vinculados por troca de
mensagens.
▶ Workflow podem ser usados com serviços baseados em
SOAP e REST.
 67

Um fragmento de workflow do Sistema de

Reserva de Hotel (hotel booking)
 68

Interação de workflows
 69

Teste de Composição de Serviços

▶ Testing is intended to find defects and demonstrate that a
system meets its functional and non-functional
requirements.
▶ Testar serviços é difícel de realizar e deve ser feito em
serviços (externos) como 'caixas-pretas’. Técnicas de teste
que contam com o código-fonte do programa não podem
ser usadas.
 70

Problemas que ocorrem em teste de Serviços

▶ Serviços externos podem ser modificados pelo prestador
de serviços, invalidando os testes que já foram
concluídos.
▶ Ligação dinâmica significa que o serviço usado em uma
aplicação pode variar – portanto, os testes de aplicações
não são confiáveis.
▶ Os comportamentos não-funcionais do serviço é
imprevisível, pois depende da carga.
▶ Se o uso dos serviços é pago, os testes desse serviço
podem ser caros.
▶ Pode ser difícil para invocar ações de compensação em
serviços externos, pois essas podem invocar a falta de
outros serviços, as quais não podem ser simuladas.
 71

Key points
▶ O processo de engenharia de serviço envolve a identificação de serviços
candidatos para a implementação, definição da interface de serviços e
implementação, testes e implantação do serviço.
▶ As interfaces de serviço podem ser definidas para os sistemas legados de
software, os quais podem então, ser reusados em outras aplicações.
▶ O desenvolvimento de software que usam serviços envolve a criação de
programas pela composição e configuração dos serviços para criar novos serviços
compostos.
▶ Os modelos de processos de negócios definem as atividades e trocas de
informações nos processos empresariais.
▶ As atividades no processo de negócio podem ser implementadas pelos serviços
de modo que o modelo de processo de negócio represente uma composição do
serviço.
▶ Técnicas de teste de software baseadas na análise do código-fonte não podem
ser usadas em sistemas orientados a serviços que dependem de serviços
fornecidos externamente.
 72

Referências
▶ SOMMERVILLE, Ian. Engenharia de Software; tradução
Ivan Bosnic e Kalinka G. de O. Gonçalves; revisão técnica
Kechi Hirama. 9ª Ed. – São Paulo: Pearson Prentice Hall,
2011.